Backup Copy Job - Monthly Backup / Archiving

[mattpayne59]

I have talked to support on this issue and basically got nowhere so I figured I would try the forum as a last shot. My backup retention requires that I keep 4 weekly backups and 12 monthly backups. I am finding this impossible to create using Veeam. I purchased this software during a promotion for version 6.5 with the promise of 7 coming with the retention policies I needed. However, they seem to be useless to me. My entire backup data is about 4TB of so. I have a 22TB NAS at my remote site for offsite storage and archival of backup jobs. After running Veeam and backup copy jobs for 2 months I have used up 20TB and my backups are failing.

So here is my question. The archival options under backup copy jobs seem to be completely useless. They create a new vbk every time you use them. Every reference I have seen to backup copy jobs says they are forever incremental. I dont understand why the archiving is any different but that was never referenced before. How can I accomplish my weekly/monthly retention without using all of my storage and keeping my backup window? I will not run two backups a night against my data... That just seems like a complete waste. Also copying the same data over the wire to my remote site multiple times is a waste and not possible.

[veremin]

Hi, Matt,

The logic behind this implementation (full backups) is to make GFS restore points completely independent on each other. Otherwise, these files would be vulnerable to potential corruption issue. Assuming that some kind of failure happened during first week and you didn’t figure it out, it would be, then, copied to the whole yearly chain, leaving you without any reliable restore point.

Every reference I have seen to backup copy jobs says they are forever incremental.

In case of simple retention scheme, it is, indeed.

Thanks.

[mattpayne59]

Well, since I have had corruption happen already multiple times with Veeam, I know that corruption can happen no matter what you do. If there is corruption in the backup copy vbk, it doesnt matter how many times you spit it out in a full backup.. It will be corrupt every time. The only fix for this would be to do a complete full backup from the source. And this doesnt really answer my question anyway. I know this is how it works and I obviously disagree... But is there any other way to do what I am trying to do?

[Gostev]

If there is corruption in the backup copy vbk, it doesnt matter how many times you spit it out in a full backup.. It will be corrupt every time.

This is exactly why Backup Copy jobs has built-in integrity check of the latest restore point with automated remediation of the detected corruption.

There are a couple of reasons for keeping GFS restore points as full backups:

1. Incremental chain spanning months/years of time is just not reasonable thing to do, as a single borked increment breaks the whole chain.

2. Full backups are often much more space efficient with image level backup. For example, 7 days worth of daily Exchange increments will easily consume 200% of full backup size.

I suppose one thing you can do to avoid storing full backups multiple times is use Windows Server 2012 with deduplication enabled as your backup repository. However, I don't really recommend that approach for the archival location. If this archive is really important to you (not just a check box), then I highly recommend keeping separate, independent and self-sufficient full backups on disk or tape.

[newfirewallman]

So if we keep full is there still a more efficient way or plan of creating the GFS point to be configured on the original backup job and not a copy job, but allow it to still go to a different repository?
Or keep it a copy job and set GFS and Repository, but only backup from the source job on a GFS instance and make it a retention VBK. Cleans up confusion, diskspace, IO, etc.

[foggy]

Blake, thanks for your suggestions, your request for this is already accepted.