Air-Gapped backup

[Ti360]

Hi everyone!

I was asked to provide an air-gapped copy of our daily backup, I need your help to figure something out.
I was targeting the Scale-out capacity tier to an S3 bucket but for that to be considered air-gapped, I need to activate the S3 object-lock feature.. then Oops! ".... Veeam does not work well with WORM model for anything. (In fact, it's only with 9.5u4 that we support WORM tapes.) Basically, Veeam will want to read and modify files repositories, so WORM models will not work well with Veeam...." so now I am back to start.

oh and for that job, I am talking about a full around 40TB+, from 20+ sites...

Any idea appreciated..!

[HannesK]

Hello,
one option could be a Veeam Cloud Connect provider that enables the insider protection.

Best regards,
Hannes

PS: writing to a WORM tape and the S3 WORM work very different. The way S3 works, we need re-tries and clean-ups from time to time. That's the reason.

[dellock6]

Tenants to tape inside Veeam Cloud Connect is another very effective option:
https://helpcenter.veeam.com/docs/backu ... l?ver=95u4
https://www.vccbook.io/3.Backups/3.9-te ... -tape.html
The advantage is that each new backup is immediately copied to tape without any retention rule to wait for, compared to Insider Protection.

[ChrisSnell]

ExaGrid's appliances feature the Veeam Data Mover. This creates a non-public share which must be accessed with a user name and password from the Veeam server. A neat security feature, which also benefits from improved backup and restore speed.

[HannesK]

well, if it is "good enough" to store the data "outside" the primary repository, then all kind of repository works (Windows, Exagrid or any other integrated backup appliance, normal Cloud Connect). You only have to make sure that there is no "second way" (domain admin credentials on a windows server) to access them.

From a technical point of view, the repository server can only be accesses by the (authenticated) Veeam data mover. No other way of access.

The (small) issue with that concept is, that a human attacker (I have not seen this as a virus yet) could manually delete all backups (also with powershell) if he owns the backup server. From my point of view, if you separate the VBR environment from production (firewalls, proper passwords, no domain credentials etc.), it is very hard to hack the VBR server. Problems (in the media) usually occur when the backup server is not secured.

What I have also heard is that one copies the backup files with an external tool. That means VBR cannot see / reach / delete this copy.