Package: duplicity Version: 0.6.18-2 Severity: wishlist Duplicity can use large amounts of resources when restoring files (see bug #676840). In extreme cases this can cause backups to become practically unrestorable. Apparently such long chains are not officially supported. However, this is not mentioned in the manpage, /usr/share/doc/duplicity nor the duplicity website, so a user is likely to be unaware of this until the first time a restore operation fails. Some sort of "best practices" document would be nice, and there should also be a mention on the manpage. If possible, duplicity could warn after an incremental backup if the backup chain is about to become so large that the available resources make restoration difficulty.
-- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.1-core2 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages duplicity depends on: ii libc6 2.13-33 ii librsync1 0.9.7-9 ii python 2.7.3~rc2-1 ii python-gnupginterface 0.3.2-9.1 ii python2.7 2.7.3~rc2-2.1 Versions of packages duplicity recommends: pn python-paramiko <none> ii rsync 3.0.9-1 Versions of packages duplicity suggests: ii lftp 4.3.7-1 pn ncftp <none> pn python-boto <none> pn python-cloudfiles <none> pn python-gdata <none> ii python-pexpect 2.4-1 pn tahoe-lafs <none> -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
