Secondary Backups

[nick3young]

Hi,

We have 10 VMs across 2 hosts which are backed up to a dedicated server in the same cabinet (running 2008 R2 with Veeam).

It's currently a worry though that *touch wood* if there is a fire in the server room, our servers could be destroyed along with the backups. So we would like to backup to a second server located in a separate building (on the same network). What is the best way of doing this? These are some options I'm considering....

• Synchronising our backup repository using a third party utility (e.g. SyncToy)
• Creating a second job which backs up to the remote server once a week (e.g. incremental Mon-Thurs, active full Fri, 2nd job full Sat)
• 'Configure secondary destination' for our existing job

Finally, we would like to archive backups on the 2nd server. We currently can only fit 21 restore points on the primary backup server. If we are backing up once a week to the 2nd server I would like to keep weekly and monthly backups... perhaps going back 12 months.

Any thoughts anyone?

Thanks
Nick

[nickfurnell]

Hi

We have a similar setup, in that we have local copies on the same locations as the primary data. Although fortunately, we do have a 2nd site, their data is copied across to us and vice versa - so both sites are active/hot and backup each other. A single Backup Copy Job does not fit in this scenario as we end up with too many 'Full Backups'.

I have had a number of discussions about long term archiving and struggle with the number of full backups I can hold. I created an article on my personal site about this http://www.talking-it.com/2014/backup/v ... l-backups/, but so far I haven't had much feedback - good or bad.

I've too much detail to write here, but if anyone wants to comment on the proposed plan I would be more than welcome to discuss the ideas here.

Looking forward to a healthy debate!
Nick

[Shestakov]

@nick3young
Hello Nick,
Your concern makes sense. I recommend to follow 3-2-1 rule.
In your case it can be achieved using backup copy job.
It will copy restore points of needed VMs to a target repository. You can customize its backup window and set desired retention policy. For archiving purposes GFS retention policy can be implemented to keep weekly/monthly/quarterly/yearly backups.
Thanks.

@nickfurnell
Thank you for participation, Nick!

A single Backup Copy Job does not fit in this scenario as we end up with too many 'Full Backups'.

Could you give more details why it didn`t work? What retention policy did you have? What backup methods did you use?

[nickfurnell]

Just to give you more detail, the Copy Backup Job has some very useful fixed 'Full Backup definitions. For example to control the number of weekly, monthly quarterly and annual backups.. BUT a single Copy Job would create 12 full copies over the first year.

During the first month: 4 x weekly Full Copies
During the first 3 months: 3 x Monthly Full Copies
During the first year: 4 x Quarterly Full Copies
At the end of the 1st year: 1 x Annual Full Copy

The business requirement is to have these same points as discreet restore points for compliance and easy of recovery - but without eating all my storage.

The proposed solution involves:-
A Full backup job to run each week for 4 weeks: 1 x Full Copy + 3 x Forward incremental
Then these subsequent Backup Copy Jobs (so I don't keep touching the source data every time)
During the first month: 1 x Full Copy + 3 x Forward incremental
During the first 3 months: 1 x Full Copy + 2 x Forward incremental
During the first year: 1 x Full Copy + 3 x Forward incremental
At the end of the 1st year: 1 x Annual Full Copy

This only then requires 5 full copies to be held with 11 incrementals of varying sizes & ages. I may be way off the mark, and adding too much complexity to the task - but I am trying to balance storage requirements with recovery points. Does this make sense?

Nick

[nickfurnell]

I've just re-read my post and maybe the Backup copy jobs don't fit at all? Regular Backups may work better - but then I can't use my WAN Accelerator?

[veremin]

This only then requires 5 full copies to be held with 11 incrementals of varying sizes & ages. I may be way off the mark, and adding too much complexity to the task - but I am trying to balance storage requirements with recovery points. Does this make sense?

What about multiple dependencies? If the first point in chain becomes corrupted, all subsequent ones will be useless. Also, don't you think that even monthly worth changes might be equal to full backup in terms of size? Thanks.

[Shestakov]

Yes, WAN Accelerator available only for backup copy and replication jobs.
But for the requirements you`ve described backup job is not the best choice. For instance:

...During the first year: 1 x Full Copy + 3 x Forward incremental

in this case an incremental run will be made 3 months after full backup and might have same size. Plus, as Vladimir said, it will be dependent on Full backup.
You can increase compression to shrink backups, but it requires more CPU resources.
Thanks.

[nickfurnell]

I take both your points.. but as always this leads to additional questions..

What about multiple dependencies? If the first point in chain becomes corrupted, all subsequent ones will be useless.

I agree with this potential flaw, hence why I suggested running multiple jobs - with each one having its own start of the chain. Weekly's and monthly's should be fine. Especially if the Quarterly and Annual backups can be straight Backup Jobs (independent of anything else)?

Yes, WAN Accelerator available only for backup copy and replication jobs...
You can increase compression to shrink backups, but it requires more CPU resources.

CPU cycles are not really a consideration, "Size on Disk" and Time is my enemy here as the "Full Site Backup" will take many hours or days to run. They may also conflict with the normal daily backup runs.

Fortunately we run two sites. So backups on Site A to my external target at Site A, don't need the WAN Acceleration. Site B to Site A backups would benefit from WAN Acc BUT given that the data change rate could be so vast, this may not actually add anything to the over all process.

I appreciate the feedback, what is the consensus on the solution.. is it a mix of Backup AND Backup Copy jobs? How long do you trust a single Chain... days, weeks or months? Should I worry that the large jobs over run the daily jobs?

Thanks again for your suggestions so far.

[Shestakov]

Nick,

I agree with this potential flaw, hence why I suggested running multiple jobs - with each one having its own start of the chain. Weekly's and monthly's should be fine. Especially if the Quarterly and Annual backups can be straight Backup Jobs (independent of anything else)?

Creating separate jobs adds complexity + may cause needless redundancy, since you need your weekly/monthly/etc. backups not to overlap each other.

I appreciate the feedback, what is the consensus on the solution.. is it a mix of Backup AND Backup Copy jobs? How long do you trust a single Chain... days, weeks or months? Should I worry that the large jobs over run the daily jobs?

From my point of view, the best solution is to keep backups on both sites, according to 3-2-1 rule. Use the backup job for production site repository and backup copy job with GFS retention policy for DR site. GFS retention is the easy and efficient way to deal with backups for archiving purposes. You can also schedule backup jobs to run only at weekends, not to intercourse with your daily jobs.
As for backup chains, they are reliable. Some users have hundreds of increments in chains, nevertheless, restoring from the end of the chain can take a lot of time.
Veeam`s Surebackup technology also helps validate backup integrity.
Thanks.

[foggy]

Also, if your secondary storage is some sort of dedupe device (or at least Windows deduplication-enabled), then all those GFS full restore points will be well deduplicated and consume less space as separate incremental chains would.

[nick3young]

Thanks for the responses everyone. So to summarise then, here is what I have done so far:

• Created a backup copy job
• Added original 'Backup Job' as the object to process
• Set 'restore points to keep' as 5 (I don't need to keep all of them on the secondary server - 5 will do I think)
• Ticked 'keep the following restore points for archive' box
• --- set weekly as 4, monthly as 3, quarterly as 4 and yearly as 1 (..... will this work for GFS??)
• I haven't changed any of the 'schedule' settings

Just a couple of other questions:

• The target for our backup copy job is a QNAP NAS box with a proprietary OS. It obviously isn't going to be as powerful as our main backup server with 2008 R2 installed. Could this cause a performance problem or will our main backup server (the source) be responsible for the majority of the processing?
• We use standard/forward incremental (with active full on a Friday)..... could this have a negative impact on our secondary backup?
• Will the GFS scheduling settings work as I have mentioned above? I have based it on what you have written Nick and this makes sense in my head....

Thanks again
Nick

[Shestakov]

Hello Nick,

The target for our backup copy job is a QNAP NAS box with a proprietary OS. It obviously isn't going to be as powerful as our main backup server with 2008 R2 installed. Could this cause a performance problem or will our main backup server (the source) be responsible for the majority of the processing?

You don`t need repository to be powerful, it should work fine.

We use standard/forward incremental (with active full on a Friday)..... could this have a negative impact on our secondary backup?

No negative impact. By the way, are you at VBRv7? Because starting from v8 we offer Forward Incremental-Forever Backup method by default. With this method, you don`t need to do active full every week. Nevertheless, standard forward incremental will work fine with backup copy.

Will the GFS scheduling settings work as I have mentioned above? I have based it on what you have written Nick and this makes sense in my head....

It will. However doesn`t fit what you wrote in your first message:
"I would like to keep weekly and monthly backups... perhaps going back 12 months."
What retention for archiving are you trying to achieve?

Thanks!

[nick3young]

Because starting from v8 we offer Forward Incremental-Forever Backup method by default

Yep we are on v8. I'll check that method out - thanks for the tip

It will. However doesn`t fit what you wrote in your first message: "I would like to keep weekly and monthly backups... perhaps going back 12 months."

Sorry.... I wasn't very clear with that was I? I wouldn't like to archive a whole years worth of weekly backups. I quite like the idea of weeklies for the current month, then monthlies until the current quarter and then quarterlies until the current year. Do you feel this is good practice or should I be archiving more than this? e.g. every month for a year.

[Shestakov]

Yes, it was a bit confusing; but, the settings you provided in the last post would work fine.

Do you feel this is good practice or should I be archiving more than this? e.g. every month for a year.

It`s totally up to you. Depends on your backup policy, capacity of repositories etc.
But weeklies for the current month, then monthlies until the current quarter and then quarterlies until the current year looks sane.
Thank you.

[foggy]

You don`t need repository to be powerful, it should work fine.

It should be pretty powerful in terms of IOPS it could provide, since backup copy is a synthetic activity that requires good random IOPS capabilities from the backup storage.