SOBR pro-actively extending

[mriesenbeck]

Hi,

I started out running a simple repo for a new installation. But the repo was running for faster than anticipated. All jobs were in place and ran succesfully. Since I forsaw that there would be more needed eventually, I first turned that simple repo into a SOBR with that one simple repo as single extent. Since I still see the usage being high I decided to create another repo and add that to the newly created SOBR. Obviously the 1st simple repo had all the backup files and the new repo has none.

What I can't find in the manual, or rather, what IS written confuses me, is what will happen once Veeam detects that the 1st extent will not have enough free space to create the next incremental backup file on it (I use FFI with daily full synthetic backups on XFS repos and data locality on the SOBR with per VM backup file enabled). Will the next incremental backup file be written to that 2nd repo extent and have I prevented a disaster, or will the next incremental backup fail? In the manual it is mentioned that all backup chain parts should be on the same extent or else the merge would fail, if I interpret correct what is written.

I basically want to know if I prevented failing backups by adding the second repo as second SOBR segment or not.

Thanks for any input you can give me.

[Gostev]

Hi.

I believe you did prevent the disaster. Congrats!

Basically, you followed to the letter one of the main use cases we had in mind when designing SOBR. We knew most customers will not care about deploying SOBR originally, but for many the time will come when they will need to turn their simple repository into SOBR to save their next backup cycle.

Thanks!

[Gostev]

I forgot to address your question. SOBR data placement policies will be breached when following them results in inability to create a backup. I expect in your case this situation will result in a synthetic full backup to the 2nd extent, then the backup chain will continue there.

[mriesenbeck]

Hi Gostev,

I'm glad to hear, it was basically what I was expecting from this feature, which could literally be a life saver. I just feel that the manual could explain this better, since if I read it literally it seems like the chains need to stay on the same extent or the merge fails. And immutable is kinda of like a double edged sword in these situations, so it's perfect from a security point of view, but moving those files to somewhere else or even deleting some backups to 'make space' isn't possible, so the old tricks to create space in the pre-immu days are not possible anymore. So you need to think ahead more and plan, calculate and correct beforehand. I am lucky there is extra space available, but if there's not and your backups are immu, you're scr@w@d. And I experienced this too, when a customer did not monitor his new physical immu and then ran out of room way before the next immu would be deleted. So..... format and restart.

Thanks for your swift reply!

[mriesenbeck]

One think error though. The extended sobr ran out of space yesterday, while there should have been plenty. But I think I know the reason. Since this newly added extent had no increments and I had selected daily synth full, the job was missing those increments and probably started to create a new full. That times 20 or so jobs and the sobr was full. So for yesterday I disabled the synth full and ran the jobs, they created increments and I did not run out of space. If you think of it, it makes sense since XFS can do fast cloning, but then the source block need to be on THAT disk (too), but with a SOBR you in fact have 2 disks, so the new one cannot have those source blocks. But it's something to keep in mind. Now here's to having enoigh space left tonight to get a non synth backup done and then have Veeam remove expired immu backups to clear out more disk usage...