Cloud Edition/AWS - Best Practices?

[Dave-Departed]

Hi All,

Been trialling Cloud Edition, which seems to work very well when testing with our test VMs, but... I have a question about what is best practice to achieve the scenario which our management requires:

Onsite:
- Keep 90 days+ of Veeam backups (already doing this)

Offsite (AWS):
- Keep 30 days of Veeam backups
- Most recent week's worth of backups remain in S3 storage
- Other 3 week's worth of backups automatically moved to Glacier using AWS Lifecycle rules
- Files deleted permanently after 30 days

What I'm unsure of is, if our onsite VBR jobs are using Forward Incremental backups, and are set to Forever Incrementals/Synthetic fulls, how can we recover from files we download from AWS in the event of a disaster? Because after 30 days from its creation, a full .vbk file would be deleted? And even though we are about to go from 10mbps to 100mbps on our ISP, I don't think we'd be able to handle uploading a full backup every week for all of our VMs...

How do other people use Cloud Edition with AWS?

Thanks in advance

Dave

[Dave-Departed]

What I mean is, I know we can use GFS policy for our onsite backups to create a full (even synthetic) backup for each VM at least weekly, but I doubt our backup window would allow for all of that data to be uploaded within 1 day.

Also, if we want to keep Monthly/Yearly backups via GFS and store them offsite on AWS, how can we do that, too?

[Dave-Departed]

Anyone? I'm at the point where I need to justify purchasing Cloud Edition in our next budget cycle, but unless I have a solid, workable plan for the above scenario, it's gonna be tough!

[veremin]

What I'm unsure of is, if our onsite VBR jobs are using Forward Incremental backups, and are set to Forever Incrementals/Synthetic fulls, how can we recover from files we download from AWS in the event of a disaster?

In fact, if the .vbk file gets deleted, you won't be able to recover from .vib files that depend on it.

Thanks.

[Vitaliy S.]

Hi Dave,

Let's wait what other community members can say on this, but I will try to address your question in the best way I can.

- Files deleted permanently after 30 days
Because after 30 days from its creation, a full .vbk file would be deleted?

What I'm unsure of is, if our onsite VBR jobs are using Forward Incremental backups, and are set to Forever Incrementals/Synthetic fulls, how can we recover from files we download from AWS in the event of a disaster?

Do you mean that these files will be deleted from Amazon storage completely (from Glacier) or just from S3 storage? In order to restore backups from the cloud you need to either have a backup server installed in the cloud (to make all the work) or download backup files and then run a restore procedure.

Thanks!

[Vitaliy S.]

Also, if we want to keep Monthly/Yearly backups via GFS and store them offsite on AWS, how can we do that, too?

See this topic that covers a similar question > Misunderstanding Veeam Cloud Edition?

[Dave-Departed]

Thanks guys, much appreciated.

Yes, I realise now that we need a .vbk present to restore, in fact, we need the full backup chain from the last .vbk to the most recent incremental, right?

So... If we were gonna do it this way, perhaps:

Onsite:
-Weekly full backups
-Separate jobs for Monthly and Yearly backups

Offsite:
-Keep most recent 8 days-worth of backup files in S3 (so at any one time, that could include 2 .vbk files maximum plus 6 days-worth of incrementals)
-Anything older than 8 days is moved to Glacier automatically

So that way, we could go back a full 7 days offsite quite easily, by downloading the oldest .vbk kept in S3

I will check out the links, thankyou!

[Vitaliy S.]

Yes, I realise now that we need a .vbk present to restore, in fact, we need the full backup chain from the last .vbk to the most recent incremental, right?

Correct.

Onsite:
-Weekly full backups
-Separate jobs for Monthly and Yearly backups

Yes, you can either use regular jobs or backup copy jobs for that.

So that way, we could go back a full 7 days offsite quite easily, by downloading the oldest .vbk kept in S3

Correct.