8

Is it possible to backup a remote directory to a local path?

Using two URL in the command raises

Two URLs specified.  One argument should be a path.

Using only one for the remote but specifying the full option raises

--full option cannot be used when restoring or verifying

What I tried looks like

duplicity full ssh://username@remote:XXXX/home/username /media/removabledrive/

with XXXX being a custom port for ssh.

Improve this question

4 Answers 4

Reset to default
17
+50

Why not just mount the remote path into your local filesystem tree using sshfs, cifs, nfs or some other facility of your choosing?

If you do that, you can specify two local paths to duplicity and it shouldn't notice that one of the paths is actually on a remote node (make sure you choose the remote file system that exports attributes like permissions etc. in a way you want and also make sure you use correct mount options - which is especially important for samba/cifs, since its defaults are not very unix-ish).

For a Debian or Debian derivatives (like Ubuntu):

apt-get install sshfs

Then:

mkdir -p /mnt/remote &&
sshfs username@remote:/home/username /mnt/remote

After that succeeds, do your backup from /mnt/remote to your local backup path, then

umount /mnt/remote

Also check out man sshfs to see what options might apply to your use case.

Improve this answer
2
  • Good idea! The only caveat is that file exclusion does not seem to work properly.
    – M. Toya
    Oct 6, 2013 at 17:28
  • I'm using this method too. I've not yet tested how the paths are "stored" though. For some background info on sshfs and its limits (especially if you have slow CPU or high latency) see superuser.com/a/197611/283120
    – Nemo
    Apr 8, 2018 at 20:44
5

Duplicity doesn't support remote sources, so there is no way to do this without tricks like suggested by @blubberdiblub.

It have disappointed me when I found the issue, although they don't call this as an issue: https://answers.launchpad.net/duplicity/+question/143932

Improve this answer
2
  • Maybe you are using a really old version of duplicity. I was backing up to an NFS share without any issues, and more recently I am backing up to sshfs shares ... also without any issues. All it requires is that the backup destination be file:///path/to/mounted/folder In fact if you read the comments in the very link you provided, edso tells the OP there " I personally mount some smaller sources with sshfs before some backups. "
    – Michael M
    Jan 23, 2018 at 22:53
  • 1
    MikeM, the answer said "remote sources", not "remote backup destinations".
    – Cray
    Oct 4, 2019 at 15:20
1

From what I understand, supplying remote path followed by local path imposes restoring data, which should be a full restore by default.

"full" parameter is only valid for making backups:

   full   Indicate full backup.  If this is set, perform full backup  even
          if signatures are available.

   incr   If  this  is  requested an incremental backup will be performed.
          Duplicity will abort if old signatures  cannot  be  found.   The
          default is to switch to full backup under these conditions.

So this command: duplicity full /home/me scp://[email protected]/some_dir will make a full backup of /home/me to remote host/some_dir. Full/incr only applies to MAKING backups, not restoring.

If you want to restore only certain path, then use:

--file-to-restore path This option may be given in restore mode, causing only path to be restored instead of the entire contents of the backup archive. path should be given relative to the root of the directory backed up.

According to documentation here: http://manpages.ubuntu.com/manpages/oneiric/man1/duplicity.1.html , what happens is:

When restoring, duplicity applies patches in order, so deleting, for instance, a full backup set may make related incremental backup sets unusable.

Also, last remark about the "ssh://" part. Try using scp/sftp, as according to documentation:

A NOTE ON SSH/SCP PROTOCOLS

   Duplicity specifies two protocol names for the same protocol.  This  is
   a  known  and  user-confusing issue.  Both use the same protocol suite,
   namely ssh through its' utility routines scp and sftp.  Older  versions
   of  duplicity used scp for get and put operations and sftp for list and
   delete  operations.   The  current  version  uses  sftp  for  all  four
   supported  operations, unless the --use-scp option is used to revert to
   old behavior.  The change was made to all-sftp in order  to  allow  the
   remote system to chroot the backup, thus providing better security.
Improve this answer
5
  • I am indeed trying to create a backup. My problem is precisely that duplicity infer the action to perform from the relative position of the URL and local path. I tried the rsync backend with no success. I'll give a go on scp.
    – M. Toya
    Oct 4, 2013 at 14:27
  • If you try to perform a backup from remote host to a local machine and can consider rsync as well, you can try it with: rsync -avz foo:src/bar /data/tmp This would recursively transfer all files from the directory src/bar on the machine foo into the /data/tmp/bar directory on the local machine.
    – Jacek Lakomiec
    Oct 4, 2013 at 14:30
  • Alternatively you can do it with one command: At local machine run: ssh root@remotehost 'duplicity full /home/username ssh://username@local:port//media/removabledrive/'
    – Jacek Lakomiec
    Oct 4, 2013 at 14:48
  • I thought about the first one but that would become awkward when there are lots of data to backup. The problem of your second suggestion is that I can ssh in only one way from local to remote.
    – M. Toya
    Oct 4, 2013 at 15:19
  • If you can ssh from local to remote, then you can use ssh tunneling and forward local port on the local machine to remote host:port, either temporarily just during the backup procedure or permanently. Check man ssh for details, look at -L options.
    – Jacek Lakomiec
    Oct 4, 2013 at 18:29
0

Looking at the documentation here: http://duplicity.nongnu.org/docs.html It looks like you should be issuing this:

duplicity full ssh://username@remote:XXXX//home/username /media/removabledrive/

Notice the double // after the host:port

Improve this answer
1
  • 2
    I still get the message Command line error: --full option cannot be used when restoring or verifying.
    – M. Toya
    Oct 4, 2013 at 8:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .