Active fulls with reversed incremental and space constraints

[Moebius]

Greetings,

I have been using reversed incremental backups for my jobs since the beginning of time, so my "real" (=active) full backups were taken several months or even years ago, when the backup jobs were first created, or when I lost the whole repository storage (yes, it happened twice) and was forced to restart everything from scratch.

Now, I'm well aware of the recommendation of taking an active full backup every now and then, and I have even personally witnessed a corrupt VM backup that was being dragged along the chain. It was a "missing ntoskrnl" case and I only discovered it thanks to SureBackup. So I'm all in favor of periodically refreshing the chains with scheduled active fulls.

The problem is that I don't have enough storage space for that. Creating an active full leaves the old .vbk file in place and creates a new one. I keep 10 restore points for all my jobs, which I consider a bare minimum, and my repository is about 80% full. Most of my .vbk files are in the range of 500-800 GB, and there's one Exchange server in particular (alone in its job) whose .vbk is 1.5 TB. I simply cannot afford having two of vbk files this big simultaneously on the repository --- let alone letting them sitting there for 10 days, until the older vbk gets deleted due to retention.

It would be so nice if an active full would behave the same way a reversed incremental does, that is, transforming the existing vbk in a rollback. But I'm afraid that even if it could do so, it would still need to store the new vbk along with the old one, at least until the job completes.

I couldn't come up with any bright idea to overcome this problem. Running scheduled SB jobs would alleviate the problem since I would at least detect VMs failing to start, but it's virtually impossible to test every and each application for all the existing VMs.

Any suggestions anyone?

[mmonroe]

I think we all eventually run into space issues when we start saving more restore points and whatnot. A Synology DS2413+ works for me. I filled it with 4tb Seagate ES-3's. My main repository is a RAID-10 IBM DS4700 with 15k drives and whatnot. But for the backup copy jobs and simply having a big chunk of real estate for work space - the DS2413+ works nicely. The performance is good and it is affordable.

[dellock6]

I did this personally when dealing with the same problem: I used the theory (always confirmed in years...) that 90% and more of restore opeartions are done from the last two days of backup.
So, if you can accept to delete at least a couple of older restore points from different backups, you can free up enough space to hold one new active full backup. Once the new full is recreated, simply wait for 7-8 days and delete the old VBK file. From here, do the same again for another job, until you refreshed all the backups.

This what I was doing with 6.5 and older. With the new 7.0, I already configured some customers to take advantage of backup copy, even without having a secondary backup storage, you can think about storing only 2 restore points of every backup, and then with a "local" backup copy create the other restore points. The trick (I need to test it, right now is only an idea) would be to aggregate different primary backups into fewer backup copy files: in this way, deduplication would kick in again and dedupe similar VMs, so at the end I hope the resulting VBK would be smaller than the sum of the originating VBKs....

Some "crazy" ideas maybe worth testing

Luca.

[Vitaliy S.]

Hi Lucio,

If I were you I would probably create another repository (using any cheap storage) for archival purposes, and keep primary repository to store only a week worth of restore points, or even less. This would allow you to have two full backup files at a time (most likely, as I'm not sure how much space your restore points take right now) on the primary repository and 10 restore points in total, on the primary repository and archival one.

Thanks!