13

It's really easy - use the --force flag. duplicity --force file:///home/user/Backup / This will probably not only restore missing files to the directories you've backed up, but also replace newer versions of backed up files if they exist, but it's better than nothing.


12

actually the above does merely achieve a backup everything while excluding some files/folders. the correct answer would be. use the highest common root folder that contains all folder you want to back up. using SOURCE="/" is the easy way to achieve that. now modify your .duply/<profile>/exclude as follows + /folder1 + /folder2 - ** Note: there is ...


10

Duplicity 0.6+ will attempt to resume a previously aborted/failed/partial backup (source). The rsync options will not help, as duplicity encrypts each tardiff file as it it created, and deletes these not yet transferred files on failure. The rsync options will allow it to resume a transfer if no encryption is in use.


8

The file selection section of the duplicity man page states: Each file selection condition either matches or doesn’t match a given file. A given file is excluded by the file selection system exactly when the first matching file selection condition specifies that the file be excluded; otherwise the file is included. This relates to the --include / --...


5

I could not find this documented; probably my Google-fu is lacking, but the flags you mentioned, A, D, and M, appear to stand for "added", "deleted", and "modified", respectively, according to the source code (in diffdir.py): log.Info(_("A %s") % (util.ufn(delta_path.get_relative_path())), log.InfoCode.diff_file_new, util.escape(...


5

In the long description of the many variants of how to include and exclude files, there seems to be one most important sentence: A given file is excluded by the file selection system exactly when the first matching file selection condition specifies that the file be excluded. According to this, you need an include option for the files you want first, so ...


4

According to duplicity and rsync man, you should try this if you stop during the upload (don't know whether it's safe during encryption): duplicity --rsync-options="-P" other_args


4

looks like you backed up to ~user/home/user/backup on the target machine. try (notice the extra slash signalling an absolute path) duplicity full /home sftp://user@hostname.com//home/user/backup or alternatively duplicity full /home sftp://user@hostname.com/backup . ..ede/duply.net


3

This comment helped me to resolve this "Remove the last corrupt backup" All the .part files are incomplete backups ll /srv/mysql/logs/duply_backup/duply_cache/duply_database/*.part Remove the incomplete backups. If you want to be more conservative the output does tell you which files were causing problems. Processing local manifest /srv/mysql/logs/...


3

Does it have something to do with Google Docs becoming Google Drive? Very likely as the Google Docs API is deprecated: Important: Version 3 of the Google Documents List API has been officially deprecated as of September 14, 2012. It will continue to work as per our deprecation policy, but we encourage you to move to the Google Drive API. I didn't bother ...


3

Duplicity creates snapshots, but in the form of compressed archives, not in a form that can be read directly. There are several ways to create snapshots. Some advanced filesystems such as ZFS and Btrfs have them as a built-in feature, as do some disk layers such as LVM. On a generic filesystem, a basic technique is to reproduce the directory tree that you ...


2

Make the source your system root SOURCE="/" and then create an exclude file at: ~/conf/<backupprofile>/exclude At this article there is a good example of exclude file: http://aguslr.github.com/blog/2012/04/18/backups-with-duply/ **/*[Cc]ache* **/*[Hh]istory* **/*[Ss]ocket* **/*[Tt]humb* **/*[Tt]rash* **/*[Bb]ackup **/*.[Bb]ak **/*[Dd]ump **/*.[Ll]...


2

Shells are designed so that scripts and interactive command line sessions look the same. That means that you can effectively retype: export PASSPHRASE=SomeLongGeneratedHardToCrackKey duplicity /etc scp://FtpUserID@ftp.domain.com/etc unset PASSPHRASE Since exporting for variables for a particular command only is common, there's a shortcut for it: ...


2

Duplicity can and does restore permissions and owner of your files/folders as they were before the backup. To restore the owner two prerequisites have to be met: The restore command has to be run as root, as only root is allowed to chown. A user named the same needs to exist on the target machine. During the restore process the files and folders will be ...


2

Duplicity does not cache gpg pass phrases by default (you can give them as env vars though). All prompts you see are from the gpg binary run underneath. Hence, when you configure your gpg into the desired state, duplicity will use it as configured and you are set. For using gpg-agent read what the parameter --use-agent does on the manpage: http://duplicity....


2

@ede and I found the same solution at the same time, in my case on the duplicity mailing list duplicity verify needs the --compare-data flag in order to verify the on-disk files, and it needs the --file-to-restore flag in order to look in the proper directory, so the final command that solved my problem is: duplicity verify --verbosity 4 --compare-data --...


2

Tilia, order matters when excluding in duplicity. the parameters are used in the order given. in your example '/root/.cache' is compared to --include /etc --include /root <-- and matches here --exclude '/root/.cache' --exclude / try to move the specific exclusion in front of the more general include eg. --include /etc --exclude /root/.cache --include /...


2

I can confirm that the Deja-Dup/Duplicity combination just makes the backing up process atrociously slow (~156x slower, in fact). I ended up wiping the Deja-Dup/Duplicity backup and just went with pure rsync. Backups are now taking as little as 15 seconds. $ rsync -a --delete /home/tim /media/tim/BackupDrive/ Unless you really, really, really need the ...


1

yes, --exclude /proc should do the trick. the duplicity man page even mentions this explicitely [1] If you are backing up the root directory /, remember to --exclude /proc, or else duplicity will probably crash on the weird stuff in there. ..ede/duply.net [1] http://duplicity.nongnu.org/duplicity.1.html


1

Manual page explains the how you can modify this behavior, so it will use something different than paramiko: SCP/SFTP access scp://.. or sftp://user[:password]@other.host[:port]/[relative|/absolute]_path defaults are paramiko+scp:// and paramiko+sftp:// alternatively try pexpect+scp://, pexpect+sftp://, lftp+sftp:// See also --ssh-...


1

I would expect you could run an incremental update without running verify first. The man page says Duplicity does not require access to archive files except when restoring from backup. but based on my testing verify (at least) counts as a kind of restoring.


1

A good solution is to use a shell script as CMD or ENTRYPOINT. If you want to pass variables into the script, you can use -e to pass any environment variables to the script: docker run -e backup-label=somelabel. This option has the advantage that you can configure various areas without interpreting parameters. I suggest to also look into the ${variable:-} ...


1

try using the clean command, which is intended exactly for this purpose. ..ede/duply.net


1

The error "Protocol mismatch." is very simple: nc doesn't use the ssh protocol to connect to the remote address and port. Regarding the actual problem: is backupper user connecting via ssh keys? If so, where are the keys kept? What I think is happening is that you test your script with another user than root. Try to run your script as root like this and ...


1

use --include-globbing-filelist instead. before 0.7.03 ordinary file list parameters were globbing agnostic. wrt. the symlink issue. this might be a corner case as the symlink resolves to a destination in an excluded folder. try including + /usr/src/linux*/.config generally use either globbing syntax or not, as outlined in the answer you linked above. ...


1

Unfortunately there is no way restoring backup with duplicity over existing files even with --force option. Here is a discussion from duplicity-talks Jeremy Polen wrote: I am working on restoring files from duplicity to overwrite the current files that are on my server. I am getting the following message: Restore destination directory /home/...


1

AFAIK duplicity can't do a backup of a remote directory to a local directory. I solve the problem in two steps. On the backup server do: Run rsync over ssh using ssh keys to sync the remote directory to a local directory rsync -avz -e ssh user@remote:/remote/directory local_directory Run duplicity from one directory to another. Use asymmetric GnuPG keys, ...


1

You could use the --dry-run option to find out. Scripting might be a chore, as you would have to parse out the phrase "Last full backup is too old, forcing full backup" from the log... but doable.


1

Seems to be a bug with Duplicity: https://bugs.launchpad.net/duplicity/+bug/662442 That thread included a couple of workarounds such as running the verify on single directories at a time vs. the entire tree. Not ideal but better than nothing.


1

This may happen if you've previously run duplicity as root. The files will belong to the root user and can't therefore be removed by a nonprivileged user. Simply changing the owner of the files will fix this, if this is the case: $ sudo chmod -R user /home/user/.cache/duplicity/


Only top voted, non community-wiki answers of a minimum length are eligible