You are not logged in.
By the way,
have you guys heard of casync: [url]https://github.com/systemd/casync[/url]
Wouldn't that be a perfect fit for xsitools? The software is LGPL2 licensed.
Or you might be using it already...
greetings
In my case, I cannot afford two reposistories because I don't have that much space on my backup disks.
The reason is, that I chose a combination of data backups, and VM backups.
But that doesn't mean that I don't want to keep more than one snapshot. Because of data deduplication, I can keep
e.g. 5 daily snapshot, without needing 5 x the space. I can be relatively sure that it will fit, because I can monitor the
system, make an avarage of how much the system grows in one day, and add plenty headroom to that.
So I would like to plead that there is a use case for this functionality. And I wouldn't mind if the backup would
take 50% more time, if I would be sure it would fit.
I have read your arguments above. But I'm not sure I agree with all of them.
> 1 - Purging orphaned blocks would be time consuming
When I take a backup of my VM with XSItools, it takes roughly 8 hours,
even if most of the data is already there. Purging the orphaned blocks with this script
takes maybe half an hour. Of course with smaller block sizes, it might take longer.
> 2 - Deleting the wrong ones would be desastrous
Is it hard to make sure you don't?
> 3 - The space you are going to save by purging a well populated repo is insignificant, as most blocks will be shared
The space used only depends on how long you keep using the same repository.
Right now, the only way to make space is deleting every data block in the repository,
and start completely from scratch. Wouldn't it be at least possible to move the blocks
from one repo to the other? If you are worried about bad blocks, you can always check
the repository.
I was testing the script to cleanup after a backup and
the script wrongly assumed certain blocks where available.
The reason seemed to be that I had files like $hash.tmp and $hash.rm
in the repository. I guess those files where leftovers from a failed backup.
For the rest it seems to work really well. Thanks!
----
I would also like to mention to the xsi developers that the functionality of
this script is not a luxury when you have limited backup space.
If you want to backup a VM of 1.5T on a disk of 2.9T, chances are that
you will be able to store quite a number of "snapshots" with xsitools, but you
wouldn't be able to initialize a new repository without deleting the old,
and be without any snapshots for the duration of the backup.
In this case it would be a lot better to manage the space within one repository,
and check your repository from time to time.
And of course the best would be if xsibackup would be able to predict the space
that will be needed before doing the backup. But maybe that would double the backup time.
lieven