Backup Copy Job GFS Recovery Points

[dualdj1]

I believe some work needs done on the Recovery Point model for backup copy jobs. It's fairly close, but with the amount of data I (and I'm sure many others) are copying to our archive, we need all the available space we can get.

Right now, I have on my jobs 3 full recovery points, within 3 actual days of each other (11/3 M, 11/4 W, 11/5 R). There is no reason (for me) to have a weekly and a monthly within a day of each other, to me those are the same recovery points. I do not need a weekly when I have a monthly available. It has been practice with all of the companies I've been with to take your monthly copy INSTEAD of the weekly for that week, not In Addition To.

It ends up being less space used, for me to keep 30 incremental points (daily for a month) along with the base full (R), no weeklys, and a monthly full, than it does to only keep 2 regular restore points, 4 weeklys, and a monthly (the second takes about double the space).

Some tuning to the process would be nice. Maybe use separate synthetic chains for weeklys? As I backup my dailies to tape, I really don't need them in my backup copy, so for me it would work best to have 1 weekly full retention point, and incrementals from there on out. The same would work for me as well on Monthlys, quarterlys, etc. Maybe make it an option to save fulls or use incremental chains for retention segments (w/m/q/y)? You are already utilizing that technology on the dailies, so it shouldn't be too major to adapt that to make other chains.

Thanks for your time.

[dellock6]

For what I understood, having GFS RPs in full VIB format was a architectural decision, and it makes sense: with backup points so far each other in the timeline, incremental files would be huge anyway, and the synthetic calculations required to restore from an increment would be a problem.

As you described your configuration, you already tuned your setup in regards to your needs. There are other users willing to have more frequent full backups, even if this means using more space.

Luca.

[dualdj1]

As you described your configuration, you already tuned your setup in regards to your needs. There are other users willing to have more frequent full backups, even if this means using more space.

Kinda, I have what I consider to be a workaround. However there's still no reason to have 2 separate full recovery points for a monthly/weekly that occur the same week, when you can simply use a pointer to identify the 1 file as both weekly and monthly. And just because I *can* use 30 incrementals to save space, doesn't mean i *like* to. That is a short term workaround, rather than a long term solution. When designing software, it's good to look at any idea that can make more efficient use of resources, and even though storage is now cheap, I personally always prefer to have as many reliable restore points as possible online, and not waste space. And I'm sure that is the VEEAM programmers' intent as well.

[luckyinfil]

For what I understood, having GFS RPs in full VIB format was a architectural decision, and it makes sense: with backup points so far each other in the timeline, incremental files would be huge anyway, and the synthetic calculations required to restore from an increment would be a problem.

As you described your configuration, you already tuned your setup in regards to your needs. There are other users willing to have more frequent full backups, even if this means using more space.

Luca.

Nobody in their right mind would archive to a non dedupe storage appliance anyways. It doesn't make sense to have restore points in incrementals.

[dellock6]

Agreed. And it also makes restore points non-independent one from the other. If one breaks, all the chain could be gone. Complete VIB files guarantee complete independence of every restore point.

Luca.

[dualdj1]

Nobody in their right mind would archive to a non dedupe storage appliance anyways. It doesn't make sense to have restore points in incrementals.

The correct statement would be: Nobody in their right mind would WANT to archive to a non-dedupe storage appliance. However many people with budget restrictions don't have a choice in the hardware they can use. We use our last generation SAN, which does not have dedup capability. We are using 2012 to perform dedup, however it hasn't provided near the space savings as we'd hoped. Yes ideally we'd have a good hardware based dedup solution. But, in reality, the ideal situation rarely occurs, so having more options available lets users tune for their environment. Let the users choose how much risk they are willing to take.

I realize losing a point in the chain would cause a loss. This is why you have another copy of each restore point (tape, offsite disk, etc). In my environment, the disk archive is simply convenience, to where I don't have to pull tapes to restore, so I'd be willing to take the risk, if it proved to help maximize my storage usage and recovery point availability.

[Gostev]

Well said.

[dualdj1]

Thanks Gostev!