Reverse Incremental Chain

[mdking]

Hi All,

Fairly quick and easy question, hopefully!

For reverse incremental chains, is there a maximum amount that veeam deem suitable? Or have veeam seen many clients with long chains of backups.

Thanks
Matt

[skrause]

With reverse incremental the only issue would be (eventually) disk space. Reverse incremental for all intents and purposes only cares about the current restore point as it pulls the "previous" reverse increment out of the current backup during processing. There might be some theoretical limit on the number of files, but I am sure it should be fine with any long chain. I had one forever forward chain that was not properly dealing with retention that had 1 full + 167 daily increments and Veeam never complained.

You would probably want to make sure to run Sure Backup on a reverse incremental that has been running for a decent amount of time to make sure it actually will function, but that really pertains to any backup mode.

[Shestakov]

Hi Matt,
In addition to Steve`s great answer(thanks Steve!) I want to add some field info about long chains with reverse incremental from one of our the most experienced solutions architects:

The biggest issue that you see is that as chains get longer there's more time spent reading metadata from the chain so startup time can get a good bit longer, but performance once you're past this point doesn't seem to have a huge impact.

This is slightly worse with forward incremental since most restores happen from the most recent point so you have to read data from the entire chain to open that point. I haven't retested with v8 but with v7 the length of the forward incremental chain didn't seem to have much impact until around 20-30 points, and no serious impact until around 90-100 points, although that could certainly vary based on the size of the backup and the speed of the storage. The storage I was testing on was reasonably fast.

On the other hand reverse incremental seemed better and I didn't see much slowdown until there were several hundred points, but there was a pretty big drop off after around 700 points or so, although FLR/Instant Restore from recent points was still not bad at all, but every other operation had a huge "ramp up" time, typically measure in 5-7 minutes.

We are going to perform more testing with the released v9.

[smd32]

With reverse incremental the only issue would be (eventually) disk space. Reverse incremental for all intents and purposes only cares about the current restore point as it pulls the "previous" reverse increment out of the current backup during processing. There might be some theoretical limit on the number of files, but I am sure it should be fine with any long chain. I had one forever forward chain that was not properly dealing with retention that had 1 full + 167 daily increments and Veeam never complained.

I have one reverse incremental job that runs 4 times a day, that I keep six months of backups for. That is a chain of 720 backups, and I have been able to restore from various points within it without difficulty.

What I really want to figure out is the best way to go past the 999 backup limit. Theoretically I can just keep copying older reversed backup increments out to another directory to stay under the Veeam 999 limit, but then it's unclear if/how I can get something back from file 1500 for example if there is no full file other than the current one from right now.

Any ideas on how to accomplish this or the additional active full is just needed every 999 times?

[Gostev]

The easiest would be to simply lift the cap in our side. As Nikita mentioned, we are planning to do some testing to see how high we can lift it. Thanks!

[foggy]

As a current workaround, you could have two jobs with the same VMs but with alternate schedules (odd and even days, for example) or use backup copy jobs for offloading data to another repository. Another way is making periodic (1 in sixth months) active fulls and offloading the entire previous chain.

[smd32]

Another way is making periodic (1 in sixth months) active fulls and offloading the entire previous chain.

Would one way of doing this be just to create a new repository and change the job to use that each time we start a new chain? Perhaps doing this monthly or quarterly if we needed very granular backups for a particular job. This is less work and time than moving the old files around and cleaning out the repository, and if you have something that can do global dedupe, you won't be taking a big hit on disk space.

Or what would be another method you like? Backup copy job still would need a new repository after 999, correct?

[Shestakov]

Would one way of doing this be just to create a new repository and change the job to use that each time we start a new chain?

This should work. I would go for another foggy`s suggestion and create 2 jobs running with alternate schedule. I.e. you schedule one to run from 8am to 8pm another from 8pm to 8am. As a result you will have 2 independent chains with up to 999 restore points.