Nuances of Active Backup for Google Workspace and snapshot replication in a DR scenario

I’m deploying a pair of Synology DS920+ units for a client and have some questions about a specific DR scenario…


The client has all of their corporate data in Google Workspace Shared Drives. I have configured and tested backups of their Google Shared Drives using Active Backup for Google Workspace, which seems to work well. I have also configured snapshot replication between the two NAS units for the “ActiveBackupForGoogle” shared folder and I have configured immutable snapshots (14 day retention) for the “slave” NAS. Following 3-2-1 principals, a third copy of their backup data resides in an Azure Blob storage account (I have configured Hyper Backup for that).

DR Scenario

A coordinated attack is conducted against my client, whereby the attackers encrypt all Google Shared Drives (i.e. ransomware software is run on a compromised Windows device to encrypt the G: drive contents). Because the “Active Backup for Google Workspace” component on the Synology is setup for “continuous backup”, any backups made after the ransomware attack would also contain the encrypted versions of files.

Assuming the attackers also compromise the “primary” Synology unit, they would delete all “Active Backup for Google Workspace” backups. However, because snapshot replication between Synology units is enabled, and because immutable snapshots cannot be modified or deleted for 14 days, the Google Shared drive data could be restored from the “slave” unit by performing a snapshot replication failover (i.e. we would choose a healthy immutable snapshot as the source) - this article seems to provide the relevant steps:

Once the recovered data is relinked to Active Backup for Google Workspace on the former “slave” unit, we would “switchover” snapshot replication to reverse the roles of the Synology units. We would then kick-off an Active Backup for Google Workspace restore job on the former “slave” unit. On the former “primary” unit, while Google Drive content is being restored on the other Synology, we would SMB share the “ActiveBackupForGoogleWorkspace” folder and on all PCs mount a network drive (G:) to that share. Once Google Drive contents have been fully restored, we would wipe clean the Active Backup for Google Workspace backup repository (simply reinstall that app?) on both Synology units, create a new backup, then setup snapshot replication again and Hyper Backup to Azure too.

I’m looking for any feedback on whether there’s an easier way to recover from the above DR scenario, or if I have made bad assumptions about how the various Synology apps function.

Nobody has any thoughts on this? Was hoping for a little feedback…


I have never used ths Google plattform so take this with a grain of salt.

  • Reuploads from NAS to GW will take a long time. If Google (like Microsoft’s Onedrive/Sharepoint) offeres snapshots if will be faster (minutes vs. days) to restore encrypet/deleted files throug Google restore tools.

  • Check if you can restore content of AB4GW to local shared folders or if you can only reupload to GW.

  • if only the latter is possible the tool of choice would be Synology Cloud Sync which, as the names suggest allows to sync the GW file content to a local shared folder (to be provisioned with SS and SSR to slave NAS)

  • use different admin accounts with different passwords for NAS#1 and NAS#2. In case you run a directory service keep the slave box out of this service.

  • use a dedicated replication user (to be created on the slave nas) that has SMB read/write access. I am quite convinced that this user is note required to be in the admin group if you find the right permission settings but I might be wrong

  • if you setup 2FA for the salve NAS and the time server connection fails the time drift between the authentication app and the NAS system clock will lock you out. No big problem if you can physically access the device to run a mode 1 reset ( How do I reset my Synology NAS? (For DSM 6.2.4 or above) - Synology Knowledge Center) BUT for this case have a HyperBackup of the NAS Settings (apps and settings only) at hand if somethings goes wrong.

Unfortunately, I don’t think Google offers snapshots.

I was able to turn the “ActiveBackupForGoogleWorkspace” backup folder into a local shared drive and enable it. With Synology Drive Server and Synology Office installed, I was then able to modify and create new Office documents via a web browser. I’ assuming this invalidates the Active Backup For Google Workspace repository from that point forward, but we would only ever do this if Google Workspace services were expected to be down for several days. Our plan is to upload any modified or new documents to Google Workspace, once they restore services. It’s a very unlikely DR scenario, but using the Synology this way does seem viable

Using Synology Cloud Sync doesn’t seem to be a better option, as we need to capture the metadata too (permissions, shares, etc). Thanks for the suggestion though, I had considered that too.

Thanks for the tip on setting different admin passwords on the Synology units.

FYI, I opened a ticket with Synology support regarding using Hyper Backup to make backups of the Active Backup For Google Workspace (ABG) app - it isn’t supported. The reason is that, after restoring the ABG repository from Azure, I discovered that it’s not possible to relink the restored “ActiveBackupForGoogleWorkspace” shared folder to a Hyper Backup task. Here’s the confirmation from Synology:

“… I checked with a colleague and she confirmed that the Hyper Backup method just flat-out isn’t supported for ABG. Apparently it runs into database issues. So… the only supported method of doing this is via Snapshot Replication…”

Pretty disappointing, since it is supported (and works) when restoring an ABB repository from a Hyper Backup made to an Azure Blob storage account.

Hopefully Synology will resolve the “database issues” and make this a supported methodology in the near future, as being 100% reliant on snapshot replication to make secondary (and perhaps tertiary) copies of the ABG backup repository isn’t a proper 3-2-1 backup strategy.