[gentoo-user] Re: Encrypted backups under Gentoo
- If your local backup becomes corrupt, then so does your remote backup, except if you are quick enough to disable the rsync step. That's why I use rdiff-backup. Yes, me too, but *inside* the encrypted container. - If you have disconnection during the rsync step (happened to me last night), your remote backup is temporarily corrupted. Shouldn't rsync do this on its own? There is an option --inplace described with: This causes rsync not to create a new copy of the file and then move it into place. Instead rsync will overwrite the existing file, meaning that the rsync algorithm can't accomplish the full amount of network reduction it might be able to otherwise (since it does not yet try to sort data matches). One exception to this is if you combine the option with --backup, since rsync is smart enough to use the backup file as the basis file for the transfer. This option is useful for transfer of large files with block-based changes or appended data, and also on systems that are disk bound, not network bound. The option implies --partial (since an interrupted transfer does not delete the file), but conflicts with --partial-dir and --delay-updates. Prior to rsync 2.6.4 --inplace was also incompatible with --compare-dest and --link-dest. WARNING: The file's data will be in an inconsistent state during the transfer (and possibly afterward if the transfer gets interrupted), so ^^^ you should not use this option to update files that are in use. Also note that rsync will be unable to update a file in-place that is not writable by the receiving user. Yes, I use --inplace, but it will still leave the remote backup inconsistent in case of an interrupted transfer. And not using it is not an option for a 25GB file (and paying for capacity on the receiving end). -- Remy signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: Encrypted backups under Gentoo
Neil Bothwick wrote: - If your local backup becomes corrupt, then so does your remote backup, except if you are quick enough to disable the rsync step. That's a potential problem with any form of backup, local or remote. The truly paranoid would use two different backup methods on two physically separate destinations. Well, it's not quite the same. In the 2-step case (local backup, e.g. using rdiff-backup, followed by an rsync of the backup to a remote location), if your local backup gets corrupted, then so does your remote one. If you just do two independent backups, even with the same method, one locally and the second remotely, if one gets corrupted, chances are the other one is still ok. - If you have disconnection during the rsync step (happened to me last night), your remote backup is temporarily corrupted. That should be fixable by having the script that runs rsync check the return value and try again if it fails. You're right, of course. I would still be more comfortable keeping the window of vulnerability (the time for which the remote file is inconsistent) as small as possible, and independent of network connectivity. That's why I was thinking in the lines of calculate diff, send diff and store remotely, update remote copy when connection has closed. -- Remy signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: Encrypted backups under Gentoo
Neil Bothwick wrote: I'm currently using it with a local server. If I decide to use the backups on a remote server too, I'll probably stick to backing up to the local server and then using rsync. It makes sense to have a copy of the backup locally and only use the much slower option of restoring from a remote host when absolutely necessary. There are at least two drawbacks to using rsync for mirroring the local backup to a remote host: - If your local backup becomes corrupt, then so does your remote backup, except if you are quick enough to disable the rsync step. - If you have disconnection during the rsync step (happened to me last night), your remote backup is temporarily corrupted. For the second problem, I'm toying with the idea of writing an rsync-like tool for mirroring one big file to a remote server, by first transmitting the changes and storing them separately on the remote machine, then performing the update on the big file after the connection has closed. -- Remy signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Encrypted backups under Gentoo
On Fri, 18 Apr 2008 09:34:49 +0200, Remy Blank wrote: There are at least two drawbacks to using rsync for mirroring the local backup to a remote host: - If your local backup becomes corrupt, then so does your remote backup, except if you are quick enough to disable the rsync step. That's a potential problem with any form of backup, local or remote. The truly paranoid would use two different backup methods on two physically separate destinations. - If you have disconnection during the rsync step (happened to me last night), your remote backup is temporarily corrupted. That should be fixable by having the script that runs rsync check the return value and try again if it fails. -- Neil Bothwick The original point and click interface was a Smith Wesson. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Encrypted backups under Gentoo
On Fri, 2008-04-18 at 09:34 +0200, Remy Blank wrote: Neil Bothwick wrote: I'm currently using it with a local server. If I decide to use the backups on a remote server too, I'll probably stick to backing up to the local server and then using rsync. It makes sense to have a copy of the backup locally and only use the much slower option of restoring from a remote host when absolutely necessary. There are at least two drawbacks to using rsync for mirroring the local backup to a remote host: - If your local backup becomes corrupt, then so does your remote backup, except if you are quick enough to disable the rsync step. That's why I use rdiff-backup. - If you have disconnection during the rsync step (happened to me last night), your remote backup is temporarily corrupted. For the second problem, I'm toying with the idea of writing an rsync-like tool for mirroring one big file to a remote server, by first transmitting the changes and storing them separately on the remote machine, then performing the update on the big file after the connection has closed. Shouldn't rsync do this on its own? There is an option --inplace described with: This causes rsync not to create a new copy of the file and then move it into place. Instead rsync will overwrite the existing file, meaning that the rsync algorithm can't accomplish the full amount of network reduction it might be able to otherwise (since it does not yet try to sort data matches). One exception to this is if you combine the option with --backup, since rsync is smart enough to use the backup file as the basis file for the transfer. This option is useful for transfer of large files with block-based changes or appended data, and also on systems that are disk bound, not network bound. The option implies --partial (since an interrupted transfer does not delete the file), but conflicts with --partial-dir and --delay-updates. Prior to rsync 2.6.4 --inplace was also incompatible with --compare-dest and --link-dest. WARNING: The file's data will be in an inconsistent state during the transfer (and possibly afterward if the transfer gets interrupted), so you should not use this option to update files that are in use. Also note that rsync will be unable to update a file in-place that is not writable by the receiving user. signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] Re: Encrypted backups under Gentoo
On Fri, 18 Apr 2008 10:44:05 +0200, Florian Philipp wrote: - If your local backup becomes corrupt, then so does your remote backup, except if you are quick enough to disable the rsync step. That's why I use rdiff-backup. rdiff-backup isn't really suitable for offsite backups because it uses no compression, making the space and bandwidth requirements double those of other methods. It also uses no encryption. Duplicity is by the same author and is aimed more at offsite backups. -- Neil Bothwick Windows Error:01F Reserved for future mistakes. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Encrypted backups under Gentoo
on Friday 04/18/2008 Neil Bothwick([EMAIL PROTECTED]) wrote On Fri, 18 Apr 2008 09:34:49 +0200, Remy Blank wrote: There are at least two drawbacks to using rsync for mirroring the local backup to a remote host: - If your local backup becomes corrupt, then so does your remote backup, except if you are quick enough to disable the rsync step. That's a potential problem with any form of backup, local or remote. The truly paranoid would use two different backup methods on two physically separate destinations. - If you have disconnection during the rsync step (happened to me last night), your remote backup is temporarily corrupted. That should be fixable by having the script that runs rsync check the return value and try again if it fails. Would not these problems be solved by something like rdiff-backup which I have been using for a short time. Its not encrypted, however and I am not sure what happened to the developer, but it does seem to work. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici [EMAIL PROTECTED] -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Re: Encrypted backups under Gentoo
On Fri, 2008-04-18 at 09:54 +0100, Neil Bothwick wrote: On Fri, 18 Apr 2008 10:44:05 +0200, Florian Philipp wrote: - If your local backup becomes corrupt, then so does your remote backup, except if you are quick enough to disable the rsync step. That's why I use rdiff-backup. rdiff-backup isn't really suitable for offsite backups because it uses no compression, making the space and bandwidth requirements double those of other methods. It also uses no encryption. It uses compression (gzip), but only for increments. signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] Re: Encrypted backups under Gentoo
On Fri, 18 Apr 2008 12:06:39 +0200, Florian Philipp wrote: rdiff-backup isn't really suitable for offsite backups because it uses no compression, making the space and bandwidth requirements double those of other methods. It also uses no encryption. It uses compression (gzip), but only for increments. Exactly, the current data backed up is as on the original filesystem, unencrypted and uncompressed. This does make for incredibly easy restoration, needing only cp, but isn't really suitable for offsite use. Duplicity is better in this respect, but uses excessive amounts of bandwidth. -- Neil Bothwick What did the first man to discover you can get milk from cows think he was doing? - anon. signature.asc Description: PGP signature
[gentoo-user] Re: Encrypted backups under Gentoo
Neil Bothwick wrote: I'm now testing app-backup/boxbackup, which seems good so far. Please report your findings on the list! I'm not all too happy about my current solution (rdiff-backup locally to a filesystem over dmcrypt, loopback-mounted from a file, followed by an rsync over ssh to a remote host), and I'd be happy to find something better! -- Remy signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Encrypted backups under Gentoo
On Thu, 17 Apr 2008 20:57:47 +0200, Remy Blank wrote: I'm now testing app-backup/boxbackup, which seems good so far. Please report your findings on the list! I'm not all too happy about my current solution (rdiff-backup locally to a filesystem over dmcrypt, loopback-mounted from a file, followed by an rsync over ssh to a remote host), and I'd be happy to find something better! I'm currently using it with a local server. If I decide to use the backups on a remote server too, I'll probably stick to backing up to the local server and then using rsync. It makes sense to have a copy of the backup locally and only use the much slower option of restoring from a remote host when absolutely necessary. -- Neil Bothwick Top Oxymorons Number 36: Alone together signature.asc Description: PGP signature
Re: [gentoo-user] Re: Encrypted Backups
James schrieb: Florian Philipp f.philipp at addcom.de writes: I'm in need of a backup tool and an advice would be helpful because I need some special functionality. I want to make backups from my laptop to a cardreader (pcmcia), making daily full and hourly incremental backups *if the card is plugged in* (which might not be the case for as long as two days). Additionally I need some kind of encryption. Hello Florian, I do not have any suggestions (yet) but as of today, I've been thinking about writing an application to process financial data, using some type of robust encryption, where the (encrypted) data files are stored onto a usb stick. The only time the app can run is when it detected the encrypted usbstick is ready I do not want to even store the data on the computer's HD. Not exactly the same thing, but similar. I'll be curious to see what ideas or existing solutions get posted to your question James Sounds like a job for good old GPG/PGP. You could encrypt and sign the data. Then no one can fake the data files and they are encrypted. -- [EMAIL PROTECTED] mailing list
[gentoo-user] Re: Encrypted Backups
Florian Philipp f.philipp at addcom.de writes: I'm in need of a backup tool and an advice would be helpful because I need some special functionality. I want to make backups from my laptop to a cardreader (pcmcia), making daily full and hourly incremental backups *if the card is plugged in* (which might not be the case for as long as two days). Additionally I need some kind of encryption. Hello Florian, I do not have any suggestions (yet) but as of today, I've been thinking about writing an application to process financial data, using some type of robust encryption, where the (encrypted) data files are stored onto a usb stick. The only time the app can run is when it detected the encrypted usbstick is ready I do not want to even store the data on the computer's HD. Not exactly the same thing, but similar. I'll be curious to see what ideas or existing solutions get posted to your question James -- [EMAIL PROTECTED] mailing list
