Questions on s3 backup and disaster recovery

[ithark]

Hello Guys,

We currently are backing up VMware VMs directly to s3.
We would like to have some clarification on what would be the impact of making a few changes.

Firstly, we are currently running a forever incremental backup system and are wondering if switching to monthly full backups would increase storage consumption and API calls on S3.
Secondly, we would like to replicate backup data from one S3 bucket to another in a different region and are seeking advice on the best way to do this in terms of cost and practicality.

Regarding the second question, we see two viable options available.
• The first option is to configure the backup copy job and let Veeam manage the replication between the S3 buckets. Will it trigger the same amount of API calls as it has on the primary backup bucket?
• The second option is to use the native AWS solution to sync the source bucket to another bucket in a different region. In this case, we believe it may make sense to add the replication bucket to Veeam and perform a daily scan of the bucket. This would ensure that the secondary S3 bucket information is already in the Veeam database in case the primary S3 bucket region is lost.
The idea behind it is to be able to fast attach the replica bucket to the new/restored Veeam instance in case of a disaster in the main region, without having to wait for indexing to complete.

[Gostev]

Hello,

1. No if you use Synthetic fulls. Yes if you use Active fulls.

2. First option will require pulling data back on-prem and pushing it to cloud again, so too expensive and slow.

Second option should work but was never tested. However, you should never add the second bucket to your Veeam install in any case because it will result in issues due to the conflicting backup IDs. You should only attach it in case of a DR situation, and normally you would use a clean freshly provisioned backup server for this. But if you want periodic rescans then perhaps you can simply keep such DR server running as it does not require additional Veeam licensing.

Thanks

[ithark]

Hi Gostev,
Thanks for your reply. I am not sure if I understood the concept of backup copy between two s3 repos.
About the following, "First option will require pulling data back on-prem and pushing it to cloud again"
Isn't the data moved directly from the source s3 bucket to the replica s3 bucket?
I don't understand why the data has to travel back on-prem, and then to replica s3 again.
Regards,
Karthik

[Gostev]

Because in Backup Copy jobs, data flows from Source to Target data mover processes, which are normally running on your on-prem backup infrastructure components aka Gateway Servers specified in the object storage repository settings (or Mount Servers, if the former is not specified).

[ithark]

Hi Gostev,
Our Backup components (Gateway server, Backup server) are EC2 instances.
Does this mean anything?
Regards,
Karthik

[Gostev]

This changes the situation of course as the data never leaves Amazon data centers. However, you need to be careful with setting this up and ensure the right IP addresses are used, to ensure data path does not hit the Internet (which would cause egress charges). I'm not Amazon expert to provide more details on this, I just know too many people who burned some $$$ due to this error.

By the way, you should consider a different cloud object storage provider for the second copy, otherwise there's no media break required by the 3-2-1 rule of backup. Natively replicating between Amazon S3 buckets is no different approach than, for example, using storage-based replication. While using Backup Copy jobs for same is tons better because data will be physically read and thus validated before it is copied, it's not ideal because it will still be a subject to the same potential bugs or infrastructure issues on both ends. Plus when using Backup Copy jobs, the costs will increase significantly due to API calls required to read the copied data.

Honestly, backing up directly to cloud object storage is rarely a great idea unless you're willing to cut some corners with the 3-2-1 rule exposing you to additional risks, or willing to spend lots of $$$. So I strongly recommend you start from testing this with a few VMs for some time to better estimate the total costs before going full scale.

[RubinCompServ]

@Gostev,

If backing up directly to cloud object storage isn't a good idea (which I agree with), why did Veeam hype that capability in 12.1?

[RubinCompServ]

1. No if you use Synthetic fulls. Yes if you use Active fulls.

An Active Full to S3 wouldn't still use the same objects that are already there?

[Gostev]

If backing up directly to cloud object storage isn't a good idea (which I agree with), why did Veeam hype that capability in 12.1?

It is backing up on-prem workloads directly to cloud object storage that is usually not a good idea. However, for cloud workloads it is a very different story

Besides, in situations when no on-prem backup storage is available in principle, for example tiny remote offices, one backup directly to cloud object storage is way better than no backups at all.

An Active Full to S3 wouldn't still use the same objects that are already there?

Correct. Use Synthetic if you want reuse, or Active if you don't want reuse.

[Matts N]

@Gostev,

If backing up directly to cloud object storage isn't a good idea (which I agree with), why did Veeam hype that capability in 12.1?

Some companies have on-prem S3 object storage, where this is very useful, besides the options to use S3 cloud providers.