Not all of the datacenter is virtualized. A few percent of the server still run on bare metal. In order to achieve complete protection of the datacenter, backup and restore of physical servers is important. In this blog let’s look at the steps involved in a physical server backup.
First step is to install the agent software on the physical servers. Cohesity agent software runs as a service and it installs a change block tracking filter driver on Windows which tracks the changed blocks of the volume. Both the agent and the driver have very minimal footprint. The agent on Linux servers supports source side dedupe. After the server is registered with the cohesity cluster it can then be protected by creating a backup job including one or more servers and attaching a protection policy to it. The policy attached is same as that of the VM protection policy that captures backup frequency, replication and long term retention details.
When the backup job run starts for the first time, the data protection component on the Cohesity cluster establishes contact with the agent and triggers a snapshot of the volumes that are protected. Cohesity agent interacts with Microsoft VSS and triggers a app-consistent volume snapshot. Since this is a first backup the CBT driver will not return any changed blocks and the data protection component performs backup of all the used blocks of the volume. The data that is backed up is stored as VHD/VHDx files in a Cohesity view (datastore that can be accessed via SMB/NFS). A VHD/VHDx file will be created for each volume in the server. Storing data in this format enables a lot of restore, test & dev and P2V workflows. We will take a look at these in a follow-up blog. Once the backup is complete, the VSS snapshot is released on the physical server. The indexing engine will now index the volume so that files and folders within the volume can be searched for recovery.
In the next backup run which happens to be an incremental backup, the dataprotect component clones the VHD/VHDx files from the previous backup run. It now instructs the agent to take the snapshot. After the VSS snapshot is taken, it contacts the change block tracking driver to obtain the list of changed blocks from the previous snapshot. These changed blocks will be read from the snapshot of the volumes and copied over to the cloned VHD/VHDx files. Essentially what we have now is fully hydrated VHD/VHDx files corresponding to the incremental run that are ready to be accessed for recovery/test & dev workflows. One of the underlying technologies that enables fully hydrated snapshots is SnapFS . The rest of the steps is similar to the previous one.
On linux physical servers LVM snapshots are used to take crash consistent snapshots and tese snapshots will be backed up. Incremental backups are not yet supported on Linux servers but Cohesity agent provides a highly efficient variable length source side dedup on Linux servers.
In a follow-up blog we can look at the various flows associated restores and test & dev.
