In general, Asynchronous Replication is used to create an independent copy of the data and store it separately from the main storage system. It allows the user to restore the data on the primary site after sustaining damage from a virus attack, disaster or just erroneous human activity. It is, basically, the backbone of backup and Disaster Recovery processes. Replication can be scheduled, in order to avoid critical high workload on the main storage system and network channels. It is typically set to a time frame outside production process, so it doesn’t interfere with the primary workload.
Snapshots are, basically, saved “states” of the system at a given time. They are typically utilized to recover from a failed state – data loss, virus infection, crash, etc.
Snapshots that were created with StarWind VSS provider are guaranteed to be consistent. StarWind VSS provider is a proprietary software, designed for internal Virtual SAN usage and should not be used for any purposes externally. It serves snapshot-supported devices, i.e. LSFS or Asynchronous Replication.
Asynchronous Replication can work through network channel(s) that is (are) significantly slower comparing to the channel(s) that client is connecting his main storage system with.
Main configuration scenarios with Asynchronous Replication
If automatic replication mode was configured, the system will work by following next algorithm:
• Create snapshot on the main storage
• Transfer snapshot to the replication site
• Delete snapshot on the main storage if necessary
• Delete the oldest snapshot on the replication site if necessary
NOTE: During the snapshot creation process, StarWind VSS provider can be used depending on the initial configuration of the replication. In case it was configured, please make sure StarWind VSS provider is also installed on the replication site.
A number of snapshots stored on the main storage and the replication site can be different.
Backing up with foreign utilities
Operations with snapshots are usually made through VSS mechanism, using VSS provider. Backup software usually uses snapshots by following next algorithm:
• Create snapshot on the main storage
• Mount snapshot
• Copy data from the snapshot to the repository with its own mechanism
• Unmount snapshot
• Delete snapshot
Checking the status of the replicated data, selective data recovery
It is recommended to check data consistency of the snapshot/backup from time to time. The easiest way to do so is to read everything from the snapshot once it was created and compare the read data to the data in source snapshot. You should mount snapshot, which you want to check and you will see additional target was created on your asynchronous node.
Also, there could be a situation when you will require the access to the snapshot in order to recover certain files without changing the state of the main storage. In order to do that, you will need to mount the snapshot from asynchronous node to the local one. After mounting the snapshot, you will be able to access the storage in “read only” mode. Mounted snapshot can cause conflicts with the main storage within the OS, we avoid that by substituting the “VolumeId”.
Full Device recovery from the snapshot (back seed)
Administrator chooses the recovery point (snapshot) and starts the recovery process on the main storage.
NOTE: During back seed procedure, initial data (data that was in the main storage before back seed procedure was started) on the main storage will be lost. During the back seed procedure, you will copy the data from selected snapshot only.
Snapshot Scheduler during the replication process
Scheduler initializes the snapshot creation process, deletes old(outdated) snapshots and makes sure to store the specified amount of snapshots on the storage.
Asynchronous replication implemented with LSFS device and ImageFile device
Log-Structured File System or LSFS, is a proprietary file system, designed by StarWind for better handling of virtualization workloads.
When working with LSFS, integrated LSFS snapshots are used. Snapshots are stored with the main LSFS device data.
When working with ImageFile, we use the additional instance, data change log. As a storage for the data change log instance we use separate storage that needs to be segregated from the main storage. Storage for the data change log instance can be specified in the asynchronous replication setup wizard.
All new data will initially be written to the to the data change log instance, after that, it will be transferred to the main storage in the background.
Having configured asynchronous replication in StarWind-based infrastructure by following this guide, the user can employ backup and DR functionality. By taking snapshots of the system “state” and sending them to a remote site (for example – public cloud), one can restore normal operation after its disruption by disaster or unplanned maintenance. With an effective snapshot schedule, data loss and failure consequences can be minimized.