I think it's reasonable to want a full backup every so often: most of my machines are configured to do one every few months. There's nothing magic about that number: the right value is going to depend on how much data you have, how fast it changes, how likely you are to want to restore from anything other than the most recent snapshot, how much traffic and storage costs you, and how paranoid you are. Other people might want a full backup every week.
Unless you do a full backup from time to time the archive size and recovery time will continue to grow.
I don't think duplicity specifically has a "check" command http://pad.lv/660895, but it would be nice if it did. It is very prudent to do a test restore every so often.
A related question is whether you should keep more than one backup chain. Again, it depends on the cost. One reason to keep one is that you could restore from it if the current chain is corrupt, either because of hardware failure, OS failure, or a duplicity bug. Of course if the old chain is very old, restoring from it may be of limited value.
Making a full backup always uploads a full copy of the data.
If the client concern is the fraction of bandwidth used, rather than traffic charges, you might want to run it under eg trickle
.
Are you sure you know what to expect in this senario? The documentation on duplicity says that it uses incremental backups, making each additional backup a patch or changeset of the previously uploaded one. Deleting any old backup files would break the chain of files needed to piece together a full data set.
It appears to have a function to periodically do a full backup to clean up the incremental change chain with new full files. Have you set that up and run one recently? How are you observing that "it still keeps all backups"? Are you looking at S3 directly?
Best Answer
The only way (IMO) would be to configure a Windows system with Google Drive (there's no Linux client yet, not sure about OSX), share the Google Drive folder, and then mount it on your target *nix system with Samba and use it as a backup target.
It would be convoluted, prone to errors and breakage, and probably perform pretty badly. But you could, if you really had to.