Hi.
I wonder if i backup through FTP to another server, will the backup copy all the files every time the backup runs, or only the new ones?
New user's registration have been closed due to high spamming and low trafic on this forum. Please contact forum admins directly if you need an account. Thanks !
FTP Backup version control
Re: FTP Backup version control
It will copy everything even if the source and destination are identical. Rsync will do intelligent copying, but requires either an SSH connection or a Rsync server running on the other machine.
Re: FTP Backup version control
Hi,
This is what I do. Please be aware that I have only tested a restore the "soft" way - i.e. never had to actually restore it after a real loss of data - only in test scenarios.
I used to use rsync directly, but even though it encrypts the transfer (depending on protocol), the files are stored unencrypted on the target machine. Some of the off-site hosts (like RandomUsername's) I trust without encryption of the backed up data, but others (like a seedbox provided by a very seedy seedbox-hosting company), I most certainly do not.
So I set up backup jobs using the built-in B3 web-interface of duplicity, and configured it to use FTP to a local account on the B3. Then I have a cron-job that uses rsync to sync the duplicity backups to off-site locations.
Duplicity claims the backed up files are encrypted, Also rsync will make one instant copy, not let you go back to a backup a few days old like duplicity claims to be able to do. In theory my solution would give me the benefit of both:
Duplicity can copy whatever amount of data it wants locally on the HDD (albeit via FTP), and then encrypt it. Rsync uses the delta and sends the difference to the remote host a few hours later.
Again - (please note!) never tested in anger, but works fine in theory and in tests - just make sure you keep a backup of your B3 settings as they are vital to restore the duplicity backups.
I have also noticed that if you have configured the B3 web interface to duplicity to save say 30 days worth of backups, it seems to rewrite the whole storage after 30 days - so every 30 days the rsync transfer is as large as the entire backup...
Cheers,
Cheeseboy
EDIT:
I might have explained why not using the SSH method of duplicity directly:
Sometimes the off-site storage locations are off-line. I'd rather have a complete backup locally, perhaps a few days out-of-sync with the remote storage, than having a backup-job fail every time the remote host is off-line.
This is what I do. Please be aware that I have only tested a restore the "soft" way - i.e. never had to actually restore it after a real loss of data - only in test scenarios.
I used to use rsync directly, but even though it encrypts the transfer (depending on protocol), the files are stored unencrypted on the target machine. Some of the off-site hosts (like RandomUsername's) I trust without encryption of the backed up data, but others (like a seedbox provided by a very seedy seedbox-hosting company), I most certainly do not.
So I set up backup jobs using the built-in B3 web-interface of duplicity, and configured it to use FTP to a local account on the B3. Then I have a cron-job that uses rsync to sync the duplicity backups to off-site locations.
Duplicity claims the backed up files are encrypted, Also rsync will make one instant copy, not let you go back to a backup a few days old like duplicity claims to be able to do. In theory my solution would give me the benefit of both:
Duplicity can copy whatever amount of data it wants locally on the HDD (albeit via FTP), and then encrypt it. Rsync uses the delta and sends the difference to the remote host a few hours later.
Again - (please note!) never tested in anger, but works fine in theory and in tests - just make sure you keep a backup of your B3 settings as they are vital to restore the duplicity backups.
I have also noticed that if you have configured the B3 web interface to duplicity to save say 30 days worth of backups, it seems to rewrite the whole storage after 30 days - so every 30 days the rsync transfer is as large as the entire backup...
Cheers,
Cheeseboy
EDIT:
I might have explained why not using the SSH method of duplicity directly:
Sometimes the off-site storage locations are off-line. I'd rather have a complete backup locally, perhaps a few days out-of-sync with the remote storage, than having a backup-job fail every time the remote host is off-line.
Re: FTP Backup version control
Hi all,
The build in backup in B3 uses duplicity which in turn uses a rsync backend to create the diff files.
It is only the diff files that are copied whether you are using ssh or ftp or storing it to a local file. Ubi, please correct me here if I am wrong, it was a while ago that I actually did work with this.
But as Cheesboy says, once the time limit runs out, the entire dataset will be copied. Haveing a time-limited backup has the benefit of not needing to run through all diff files when doing a restore.
/PA
The build in backup in B3 uses duplicity which in turn uses a rsync backend to create the diff files.
It is only the diff files that are copied whether you are using ssh or ftp or storing it to a local file. Ubi, please correct me here if I am wrong, it was a while ago that I actually did work with this.
But as Cheesboy says, once the time limit runs out, the entire dataset will be copied. Haveing a time-limited backup has the benefit of not needing to run through all diff files when doing a restore.
/PA
Re: FTP Backup version control
I don't think rsync makes the diffs, but just ships them to remote. But the idea remains the same. Oddly, once you have the diffs, the rsync transport is just used as a wrapper for SCP... 