Feature Request:How to gradually clean up old restore points

[pkelly_sts]

I thought I'd flag this as a FR in case it hasn't already been requested.

We've migrated to a number of new jobs recently (due to vCenter migration & the need to be able to *re-seed a backup after the migration to our remote copy destination) but obviously want to keep the RPs of the previous jobs more-or-less in line with our standard policy which in our case right now is 42 RPs.

The problem is, the new jobs RPs store will be gradually growing (up to 42) but without running a job against the old backup file(s) there's no way to clear them down from day to day meaning that our only real choice is to wait until we're 42 RPs into the new job before we delete the old in one swoop. Problem is, by that time we'll actually have a total of 84 RPs sitting on disk & there's a chance that we (and probably many people) won't actually have enough space to keep that amount of RPs lying around.

(*If it wasn't for the need to re-seed I'd have just re-mapped the new job to the original backup files)

Any suggestions on how to manage this other than waiting until 42 days has elapsed & just deleting?

[PTide]

Hi,

Your feature request is noted. Here is what you can try to do now:

Create a new backup job with "transform previous backup chains into rollbacks" and synthetic full options checked and map it to the old backup chain and start the job. It should create synthetic full and transform all incrementals into .vrbs. The process will take a significant amount and will create a siginificant load on the backup storage so schedule it for the weekend. After that you can disable the job and delete vrbs starting from the oldest manually ot via script on a daily basis until they all are gone.


Thanks!

[pkelly_sts]

Ah, an interesting approach, thanks, I'll take a look at that...

[PTide]

I've reread the original post and it's not clear to me why won't you just map the new job to the old backup chain and keep the retention settings effective? Please elaborate.

Thanks

[pkelly_sts]

I knew that was coming at some point!

I needed to seed a new copy to remote site because I was migrating VMs from one vcenter to a new one so that resulted in a full backup anyway.

I probably could have tacked that onto the original, but then I'd have (presumably) had to "seed" the whole 42 restore points as well.

In retrospect i guess what I could have probably done is map the job back to the original files, then created a local backup copy, and seeded /that/ to the remote site, but I was kind of having a clean-up anyway (revised job name, different repository placement etc.) so just started afresh.

[foggy]

If you have previous 42 restore points as a separate chain, then you should manually take care of their retention. I'd copy them in some other location until the new chain reaches the required number of restore points.