Restore vs. Recover
Let’s begin with a discussion on the differences between a restore and a recover in VMware DSM. The most significant difference is that a restore operations recovers the whole of the VM, Guest OS and the database which is running in the VM. We do this to avoid propagating any virtual machine issues that might exist in the current database to the restored database database. The restore operation involves the deployment of a new Photon OS OVA, the installation and configuration of DSM components, and the creation of a new database before the original database contents are restored. As such, a restore is not an in-place restore, but instead creates a whole new database VM. therefore the restore task requests that you give a new VM name as part of the workflow.
Recover operations are in-place and operates on the same database VM. Recover is intended to be used as a fast, ‘get out of trouble’ tool. If recover fails because there is some problem outside of the database data, such as a database VM Guest OS issue, a restore operation would be required rather than a recover operation.
Backing up and restoring PostgreSQL databases
Database backups and restores are implemented on PostgreSQL using the pgbackrest extension (https://pgbackrest.org/). VMware Data Services Manager (DSM) has used this mechanism since version 1.4. This mechanism uses the WAL (Write-Ahead Log). This means that DSM can restore to any PIT (point in time). This feature uses incremental backups. Thus, when there is a restore, a full back up is first restored. Then the incremental backups are applied, one by one, to get to the desired/requested PIT.
A PIT restore (PITR) includes a replay of transactions held in the backed up transaction logs. Transaction logs in this case refer to the WAL mentioned previously. WAL is the mechanism that PostgreSQL uses to make sure that no committed changes to the database are lost. Transactions are written sequentially to the WAL. A transaction is considered to be committed when the associated writes are flushed to disk. Afterwards, a background process writes the changes into the main database cluster files (also known as the heap). In the event of a crash, the WAL is replayed to make the database consistent.
Here are some screenshots taken of the running processes before and during a backup of a PostgreSQL database which has been provisioned via VMware DSM. The pgbackrest processes have been highlighted.
Before backup
During backup
Highlighted above are the pgbackrest processes used to take the backup of the PostgreSQL database.
Backing up and restoring MySQL
For backing up and restoring MySQL databases, DSM uses Percona’s xtrabackup tool. If a backup is initiated on a standalone MySQL database, the following tasks are observed. The backup script, when executed, calls xtrabackup with the necessary configuration options to complete the backup, which in this case is incremental.
As mentioned in the PostgreSQL section, a MySQL restore operation similarly involves the deployment of a new Photon OS OVA, the reconfiguration of the VM, the installation and configuration of DSM components, and the creation of a new MySQL database. The original database contents are then restored. In the vSphere client, the following tasks will be observed during a database restore.
Deploy OVA
Reconfigure Tasks
We can observe various configuration steps taking place after the OVA has been deployed and before the Database VM is powered on.
Backing up and restoring MS SQL Server for Linux
Let’s now turn our attention to the third database. This is MS SQL Server for Linux, which is now available as early access in VMware Data Services Manager. In this case, the database is backed up using SQL commands such as BACKUP DATABASE and BACKUP LOG, which are run by the sqlcmd utility. These are included as part of the adapter which is installed on all database VMs by VMware DSM. Here is a screenshot of such an operation.
Similarly, there are restore and recover SQL scripts for SQL Server for Linux which carry out these specific operations.
Hopefully you now have a good idea about how backup, restore and recover all work with VMware Data Service Manager. Feel free to leave a comment with any questions you might have on these operations.