tsightler wrote: 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.
skrause wrote: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.
foggy wrote:Another way is making periodic (1 in sixth months) active fulls and offloading the entire previous chain.
smd32 wrote: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?
Users browsing this forum: No registered users and 1 guest