Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

herrep

Member

From: Munich

Registered: 2019-07-08

Posts: 107

XSIBackup-DC --backup: Use of --rotate in a deduplicated backup repo

Hi,

What I understood from XSIBackup-DC is that the --backup action will result in a repository with deduplicated elements. This confuses me in how far an option like --rotate can be applied.  According to my understanding, --rotate assumes a sequential approach of storing differential backup data so that you can simply delete the oldest portions that you do not longer need. But how does this work in a deduplicated scenario?

I would be grateful for an explanation under what conditions --rotate can be used.

Best regards,
Peter

admin

Administrator

Registered: 2017-04-21

Posts: 2,072

Re: XSIBackup-DC --backup: Use of --rotate in a deduplicated backup repo

--rotate in a deduplicated repository is equivalent to pruning as much backups as to satisfy the rotation figure. Use to your discretion.

herrep

Member

From: Munich

Registered: 2019-07-08

Posts: 107

Re: XSIBackup-DC --backup: Use of --rotate in a deduplicated backup repo

I read your post about pruning and your concerns. I assume these concerns also apply to --rotate?

Would you rather suggest to start a new repo each month instead of using --rotate=30 to keep the latest 30 daily backups? And then deleting an entire outdated monthly repo?

admin

Administrator

Registered: 2017-04-21

Posts: 2,072

Re: XSIBackup-DC --backup: Use of --rotate in a deduplicated backup repo

Pruning is OK, we use it for our VMs, still you need to know how things work to take good decissions and pruning is an intrinsically risky action by definition, there's nothing that can be done to make pruning safer, as it consists in deleting the blocks [b]not in[/b] some set, the only way to know which blocks are to be pruned is to look for them and to delete the ones that can't be found.

What could be a fatal scenario?: your FS gets corrupted and some block name character is lost. If you don't prune, you could still recover that block manually by a partial match in the hash. If you prune, you loose it.

As said, we use pruning and we haven't had an issue so far, still, we keep multiple copies of our data at different levels and we make a full VM replication from time to time. If we were more commercially oriented, we would just not talk about it, yet (c)XSIBackup was conceived to fill some niche of users that do like to openly talk about everything concerning their data, namely: how all sys admins should be.

In an enterprise environment you normally want to keep a historic set of data, as much backwards in time as possible. (c)XSIBackup offers a huge compression ratio that will allow you to keep hundreds of restore points at practically no extra cost in storage, thus: why pruning?, to liberate a ridiculous amount of space?

There may be special cases of enterprises generating a vast amount of temporal data everyday, it's not usual but can happen. In those cases the sys admin will have to choose the best methodology for them.