[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Proposal of new feature
From: |
Peter Schuller |
Subject: |
Re: [Duplicity-talk] Proposal of new feature |
Date: |
Tue, 4 Dec 2007 21:14:18 +0100 |
User-agent: |
KMail/1.9.7 |
> Yes, that would definitely be a big relief in the cases where you have a
> lot of data to backup over a slow line (like for a personal offsite
> backup typically).
> It took me 10 days to upload my first full backup, I can't really do
> that even every month :(
For avoiding big transfers I think the killer feature would be rolling backups
like rdiff-backup does. I am not yet familiar enough with the on-disk backup
format to know whether this is possible without huge re-designs, but from a
user perspective it would totally rock.
As for the original question, I definitely see that it makes ense. Given a
finite amount of disk, one just wants to utilize it as well as possible. As
long as the remote destination will fit more than one full backup +
incrementals I think it would work well in practice, as long as you don't
have *huge* spikes in data changes.
But for truly optimizing usage with a single full backup + incrementals, only
to switch to the next full backup at precicely the right moment - feels
difficult. I'd recommend Amazon S3 if this is a concern ;)
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org
signature.asc
Description: This is a digitally signed message part.