[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] Backup from FTP via curlFTPFS
From: |
Bram Schoenmakers |
Subject: |
Re: [rdiff-backup-users] Backup from FTP via curlFTPFS |
Date: |
Tue, 9 Jun 2009 20:28:11 +0200 |
User-agent: |
KMail/1.11.4 (Linux/2.6.29-ARCH; KDE/4.2.4; i686; ; ) |
Op dinsdag 9 juni 2009 02:02:42 schreef Matt:
> Hi,
>
> I've recently been helping some friends backup data from a shared web
> host to which they only have FTP access. After some trial and quite a
> lot of errors, I've found that I can do this using curlftpfs (an FTP
> FUSE filesystem) as the source for rdiff-backup. My approach hasn't
> been very scientific but I've got it working reliably using the options
> below:
>
> --snip--
> # Mount single-threaded and readonly
> /usr/bin/curlftpfs -s -r user:address@hidden /some/mount/point
>
> # Backup to local disk (inodes may change between mounts?)
> rdiff-backup --no-compare-inode /some/mount/point /path/to/backup
>
> # Done
> unmount /some/mount/point
> --snip--
>
> Setup was rdiff-backup 1.2.5 and curlftpfs 0.9.1 (libcurl/7.18.2 fuse/2.5).
>
> It's rather slow but, with only FTP access available, it's a pretty good
> solution. Hope someone finds this useful.
The problem with mounting remote, virtual, file systems is that there's only
one rdiff-backup instance running: at the client. To compare a file, the whole
file is transparently downloaded from the remote site. If it differs, the
whole file is uploaded back + a delta. This is not something rdiff-backup can
do much about, it doesn't know any better than that it is a local file system.
The advantage of having rdiff-backup at the remote site is that client and
server can efficiently communicate what has changed and only toss over the
deltas.
Kind regards,
--
Bram Schoenmakers
What is mind? No matter. What is matter? Never mind.
(Punch, 1855)