[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] Incremental, automated, remote, secure
From: |
Greg Troxel |
Subject: |
Re: [rdiff-backup-users] Incremental, automated, remote, secure |
Date: |
Tue, 02 Jul 2013 08:36:49 -0400 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/23.3 (berkeley-unix) |
"Edward Ned Harvey (rdiff-backup)" <address@hidden> writes:
>> From: rdiff-backup-users-bounces+rdiff-
>> address@hidden [mailto:rdiff-backup-users-
>> address@hidden On Behalf Of Grant
>>
>> I'm struggling to devise an incremental, automated backup scheme that
>> remotely and securely backs up data from one system to another,
>> preserves permissions and ownership, and keeps the backups safe even
>> if the backed-up system is compromised. Would the following work?
>
> What are you calling "compromised?" Because the proposed solution you
> mentioned didn't even mention encryption. So I guess you must be
> saying "compromised" when you're really talking about the backup
> system being damaged or otherwise suffering data integrity failure.
>
> Either way, the answer is, "you can't, with anything, ever."
>
> If you are talking about security compromised, then all you can do is
> encrypt data before it leaves original server, and run integrity
> checks on it. You'll keep your data private, even on a compromised
> system, but you'll be subject to tampering. You'll be able to detect
> tampering, but you will not be able to recover.
>
> If you are talking about integrity compromised, on both your original
> and backup systems... Well ... Then the data integrity was
> compromised on both your original and backup copies. Sorry, nothing
> can protect you from that, except having more redundant copies.
I think the OP was talking about
client with data to be backed up
server to store backups
at some point, *client* is compromised
the desired security property is for the client not to be able to
modify/delete the backups that happened before the compromise
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, (continued)
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Grant, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Dominic Raferd, 2013/07/19
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/19
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Dominic Raferd, 2013/07/19
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/19
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Grant, 2013/07/21
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Dominic Raferd, 2013/07/22
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/19
Re: [rdiff-backup-users] Incremental, automated, remote, secure, Edward Ned Harvey (rdiff-backup), 2013/07/02
- Re: [rdiff-backup-users] Incremental, automated, remote, secure,
Greg Troxel <=