A regular failback procedure implies that the final recovery step is performed on the local production site directly from the cloud archive, see p.4 here: Performing a failback.
However, if the internet connection on the production site is not good enough and the amount of data on the server is large, the recovery from the cloud might take a significant amount of time. For example, it might not be possible to complete the failback within the weekend or another reasonable maintenance window.
Use the Large Scale Recovery (LSR) service tools to download both the base full backup and all the incrementals. It might take a long time, however, all that time the recovery server is still running in the cloud, is functional and is backed up with the DR service backend to the original archive.
Then the downloaded archive can be updated with the latest incremental slices, that should take much less time then downloading a whole archive.
The last step is performing a local recovery from the updated LSR archive per any of the standard procedures: see Recovering a machine
To perform these steps, you need archive_io_ctl and archive_ctl tools that are part of the LSR service. You can download them here.
- Make sure that you have made at least 1 successful backup of the running recovery server: see Backing up the cloud servers.
- Make sure that you are using backup Version 12 format. Version 11 cannot be updated incrementally.
- Download the archive .tib file via the LSR tool or via archive_io_ctl. Example command:
archive_io_ctl --astor <your data center>.acronis.com:44445 --cert <cert.CRT> --copy /1/<archive name>.tibx --show-progress --infinite-timeouts
For this command to work properly, you should:
- have your cloud certificate
- know the archive file name, for that please use the following command to view all the archives on the cloud storage:
archive_io_ctl --astor <your data center>.acronis.com:44445 --cert <cert.CRT> --ls=/1
- know the data center name (can be taken from the account management console under the corresponding tenant settings: in Clients, select the tenant and under Location find Backup storage:
In this example, it is baas-fes-eu4.acronis.com
- When you are ready for the actual failback, follow the preparations steps 1-3, as described in Performing a failback.
- Make sure that the backup, initiated with the failback, succeeded.
- Update the .tib file, downloaded in p.3 above, with the latest slices. Please pay attention, that in this command a different utility is used: "archive_ctl". Example command:
archive_ctl --file <local archive name>.tibx --mode=append --replicate-from /1/<archive name>.tibx --astor <your data center>.acronis.com:44445 --cert <cert.CRT>
- In the backup management console, add the location with the updated .tib file to Backup Storage -> Locations or use a bootable media and restore locally from the .tib file location. Two archives with the same name might appear in the new location: file-level (without recovery points) and the archive with the actual backups (with all the created recovery points).
- Perform a regular recovery: see Recovering a machine
The following recovery scenarios have been successfully tested by the Acronis QA team:
- Recovery from the latest increment (local archive) to the original server (started from the backup management Console).
- Recovery from the latest increment (local archive) to the same machine under Linux bootable media.