Veeam with offsite to tape and cloud (Glacier)

[lagrian]

Hi All,

I am new to Veeam and have just purchased Veeam Cloud edition for a virtual backup requirements.

Setup is:
Veeam Server: Windows 2012 on ESX Host
Full Backup Set Size: 5TB (Uncompressed / No Deupe)
Backup Storage: DAS on ESX Host

Want I am trying to figure out is how best to configure Veeam taking into account local backups, off site to tape and also off site to Amazon glacier.

Business objectives at a high level is the following:
* Local restore 14 Days Quick restore
* 2 offsite solutions (one to tape one to cloud)
* Tape solution to have permanent full monthly backups
* Cloud to have 6 Months data with with undecided frequency of restore points.

Without going into the detail I am finding it hard to come up with an architecture to achieve the above. What I have sketched out conflicts with each other that is:
* Local Backup is best suited to reversed incremental for quick restore and low disk space
* To Tape is best suited to Incremental - Why is this vs reversed incremental?
* To Cloud with Glacier I am still trying to work out for a rolling six month period. How would you do this? I am guessing standard incremental? with a full every month. Is it okay to have 30 odd Incrementals? i would have separate jobs for each VM and stagger the jobs so transfer is possible in the time period.
* Should I use windows 2012 deduplication?, if i do this would help local storage size which I don't have in abundance but the files stored in the cloud wouldn't be compressed so i would have long transfer and higher storage costs.

Am I missing something obvious that would enable me to do this sensibly without having mixed methods of backups, deduplication and compression options or am I over thinking this?

Any pointers would be much appreciated.

Thanks
Adrian

[dellock6]

Backup Storage: DAS on ESX Host

This is a first error to me, DO NOT save your backups into the same system you are protecting. If you loose it, you loose at once both the production data and your backups. Use an external NAS instead.

* Local Backup is best suited to reversed incremental for quick restore and low disk space

Exactly, but if you need to also ship the same backup to a different location via tape and/or Cloud Edition, forward is best suited. To use the best of both, you can consider using synthetic full with transforms, basically you run a forward so remote copies can leverage its advantages, and after you shipped away those copies you convert them into reverse increments to save on space. Be careful however it's a heavy task for your backup storage, so it needs to be sized accordingly.

* To Tape is best suited to Incremental - Why is this vs reversed incremental?

Because with reverse you update the full vbk every day by injecting into it the increments, and so the second piece of the backup (tape offload or cloud edition, no difference) sees a new full VBK file everyday, and it's copy could take hugh amounts of time. With forward, a backup file is no more touched or modified once it's created, so at every run the offsite copy replicates only the newly added VIB (incremental) file.

* To Cloud with Glacier I am still trying to work out for a rolling six month period. How would you do this? I am guessing standard incremental? with a full every month. Is it okay to have 30 odd Incrementals? i would have separate jobs for each VM and stagger the jobs so transfer is possible in the time period.

You copy to Glacier the forward incremental files you create with the local backup jobs. How much of them you could send to Glacier depends on your budget (the more backup files, the more the bill coming from AWS) and upload bandwidth you have. Cloud schedule is completely separated from standard Veeam schedules.
One suggestion: try to aggregate VMs in the same jobs, so you can increase the deduplication Veeam can reach.
This also regards the 2012 deduplication, it can help but as you said replication to Glacier could only be helped with Veeam own deduplication.

Luca.

[lagrian]

Thanks for the response and information this really helps.

This is a first error to me, DO NOT save your backups into the same system you are protecting. If you loose it, you loose at once both the production data and your backups. Use an external NAS instead.

Fortunately the host by the time the backups go live it will have no production data on it as this will be moved to a SAN. This DAS will be for backup data only and Veeam VM guest will be using local storage in server chassis.

Exactly, but if you need to also ship the same backup to a different location via tape and/or Cloud Edition, forward is best suited. To use the best of both, you can consider using synthetic full with transforms, basically you run a forward so remote copies can leverage its advantages, and after you shipped away those copies you convert them into reverse increments to save on space. Be careful however it's a heavy task for your backup storage, so it needs to be sized accordingly.

I suspect the timing of jobs becomes all the more important, thanks this is something I will look into and sounds interesting now that I read a little around it.

Because with reverse you update the full vbk every day by injecting into it the increments, and so the second piece of the backup (tape offload or cloud edition, no difference) sees a new full VBK file everyday, and it's copy could take hugh amounts of time. With forward, a backup file is no more touched or modified once it's created, so at every run the offsite copy replicates only the newly added VIB (incremental) file.

Makes perfect sense, thanks

You copy to Glacier the forward incremental files you create with the local backup jobs. How much of them you could send to Glacier depends on your budget (the more backup files, the more the bill coming from AWS) and upload bandwidth you have. Cloud schedule is completely separated from standard Veeam schedules.
One suggestion: try to aggregate VMs in the same jobs, so you can increase the deduplication Veeam can reach.
This also regards the 2012 deduplication, it can help but as you said replication to Glacier could only be helped with Veeam own deduplication.

This is interesting thanks. How many increments do you think its safe to have in a chain regardless of cost? from a integrity/safe to restore point of view? The cloud product seems basic and you can only copy flat files so I am not sure how best to do a full every so often to the cloud and then increments that are part of an integral chain.


Thanks for all your help

Kind Regards
Adrian

[dellock6]

If you are going to use synthetic full (regardless you also creates transforms or not) the longest chain you can create is 7 days, since you can only schedule synthetic operations based on the day of the week. And to me it makes sense right because those operations are really I/O intensive (I've written a whitepaper abouthttp://www.virtualtothecore.com/en/?p=3027) so a longer chain will basically stuck your backup during synthetic creation or even more during transforms.

Luca.

[lagrian]

I read your article, thanks for the explanation it has gone a way to helping me out.

As my DAS has 15k SAS disks in raid 10 I am going try synthetic full with transforms and do this weekly and see how it handles the I/O

I am now stuck on one last issue which is where I think I may differ to others that is if one of my offsite solutions sets the archive bit how can I backup the correct files with the other?

[dellock6]

I'm not sure if Veeam Cloud Edition sets or changes the archive bits, it simply copies files based on the criteria you use to select them. Never checked it, maybe someone from Veeam can answer this.

Luca.