I choose these 2 dirs because tklbam-restore creates a large /mnt/var/cache/tklbam/restore and unpacks the backup rootfs in /mnt/tmp/tklbam-xyz123
On top of that, the actual copying of the files being restored is written at the right place, say in /srv.
This means that the rootfs of the system must account for 3x the size of the data in the backup!!! (might be between 2x and 3x if the data is compressible by duplicity, i.e. not really with images, media and such). I don't know about you but that sounds like a pretty hefty price to pay!
I know there's a "--no-rollback", perhaps this saves space? Also I will try the "--restore-cache-size=10%" maybe?
Another obvious solution I can think of is to exclude THE large directory I have and manually copy it into place but I am afraid /tmp/tklbam-xyz gets deleted when tklbam-restore completes.
Still an issue on ec2 instances
I have created an instance through the hub with a 10 gig drive.
I have written 4GB of urandom data in /mnt/tmp/randomcrap and in /mnt/var/cache/randomcrap.
Sure enough, after that:
I choose these 2 dirs because tklbam-restore creates a large /mnt/var/cache/tklbam/restore and unpacks the backup rootfs in /mnt/tmp/tklbam-xyz123
On top of that, the actual copying of the files being restored is written at the right place, say in /srv.
This means that the rootfs of the system must account for 3x the size of the data in the backup!!! (might be between 2x and 3x if the data is compressible by duplicity, i.e. not really with images, media and such). I don't know about you but that sounds like a pretty hefty price to pay!
I know there's a "--no-rollback", perhaps this saves space? Also I will try the "--restore-cache-size=10%" maybe?
Another obvious solution I can think of is to exclude THE large directory I have and manually copy it into place but I am afraid /tmp/tklbam-xyz gets deleted when tklbam-restore completes.
Any thoughts?