[Duplicity-talk] How much free space can I assume?

[Ben Escoto]

I would like to change the way files are restored, but it may require
extra free space on the disk.  So I'd like to know if anyone here had
opinions on which tradeoffs were acceptable.


Right now, when files are restored (here I'll suppose the whole
archive is being restored), duplicity first downloads the full set
volume by volume and lays it out completely.  Then it downloads the
first increment, and patches all the files.  Then it downloads the
second increment, etc.

    What I'd like to do is download the first volume of every relevant
backup set (full and increment), and create any relevant files, and
then move on to the second volume of each set, etc.  So the picture
here is that we get data streams from all the sets and they get
integrated once and then the restored files are written in a single
pass.


Unfortunately, this may require a lot of disk space.  Suppose there
are 100 increments.  Then downloading the first volume of each could
take up 100*50MB = 5GB.  Maybe I could lower the volume size from 50MB
to 5MB, and then the space required would be 100*5MB = 500MB.  Is this
acceptable?

    Note too that the first way in theory has an unbounded extra space
requirement - suppose that the full backup contains a 10GB file.  Then
the next day you replace it with a symlink.  In the process of
restoring duplicity would need to create the 10GB file, only to erase
it and replace it with the symlink when it got to the second set.  The
second strategy would not need the 10GB, because it would have access
to all the increments at the same time (it would notice that the final
state is a symlink and not bother writing the 10GB file).


Anyway, opinions welcome.


-- 
Ben Escoto

pgpXqSUXSN_rz.pgp
Description: PGP signature