Offsite policy discussion

[lando_uk]

Hi

I'm just after a general consensus here. May I ask, what your offsite/DR policy is in regards to retention (number of restore points)

Do you have the same amount of copies offsite as your primary backups? So in the event of a DR you still have the historical backups?

or

Do you just copy the most recent (or maybe a weeks worth) just for restoring service, and in the event of a DR you accept the loss of historical data.

Of course is boils down to money really and what the business is prepared to pay, but I'm just curious what others currently do.

Cheers

[Shestakov]

Hello Mark,
In short, answering your main question, our suggestion is:
- Keep short backup chains on the onsite high-performance repository
- Use offsite repository for historical/GFS backups

The question has been fully covered in our ultimate VM backup architecture blog post.
Please get familiar and ask additional questions if you have any. Thanks!

[foggy]

I would also note that it is rather defined by an acceptable data loss adopted in your company, so while you can indeed review what others do, the most important criteria are still your own backup retention requirements.

[lando_uk]

Hello Mark,
In short, answering your main question, our suggestion is:
- Keep short backup chains on the onsite high-performance repository
- Use offsite repository for historical/GFS backups

The question has been fully covered in our ultimate VM backup architecture blog post.
Please get familiar and ask additional questions if you have any. Thanks!

Hi, we installed Veeam a couple of years ago now (originally v6), many lessons have been learnt and I'd install it differently if I had the chance today. Having primary backups on the same SAN as your VM's wasn't considered back than mainly due to the lack of copy jobs in v6 (we used robocopy originally to offsite). I think its past time a new design was on the agenda as full backups are now leaking into Monday morning which probably wouldn't happen if we used fast primary storage.

More to think about

[Shestakov]

Well, you can either try to upgrade your primary storage or make some troubleshooting of backup process starting from the bottleneck analysis.
Thanks.

[lando_uk]

I would need about 50TB of primary storage to implement the "ultimate VM backup architecture" That would be very expensive using 10K SAS RAID10, it would be nice to work somewhere who has that kind'a cash to splurge. The bottleneck is my NL-SAS Raid6 I know that, the best I can possibly do is NL-SAS Raid10, which I have done on some of my repositories already.

[Vitaliy S.]

For backup copy jobs targeted to the offsite storage fast performance is not required, so you can start re-architecturing your Veeam backup infrastructure (once there is a budget).