Re: [gentoo-user] {OT} Are "push" backups flawed?

[Pandu Poluan <pandu@poluan.info>]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

On Nov 12, 2011 12:58 AM, "Grant" <emailgrant@gmail.com> wrote:
>
> A little while ago I set up an automated backup system to back up the
> data from 3 machines to a backup server.  I decided to use a
> push-style layout where the 3 machines push their data to the backup
> server.  Public SSH keys for the 3 machines are stored on the backup
> server and restricted to the rdiff-backup command.  Each of the 3
> machines pushes their data to the backup server as a different user
> and the top directory of each backup is chmod 700 to prevent any of
> the 3 machines from reading or writing a backup from another machine.
>
> I've run into a problem with this layout that I can't seem to solve,
> and I'm wondering if I should switch to a pull-style layout where the
> backup server pulls data from each of the 3 machines.
>
> The problem with my current push-style layout is that if one of the 3
> machines is compromised, the attacker can delete or alter the backup
> of the compromised machine on the backup server.  I can rsync the
> backups from the backup server to another machine, but if the backups
> are deleted or altered on the backup server, the rsync'ed copy on the
> next machine will also be deleted or altered.
>
> If I run a pull-style layout and the backup server is compromised, the
> attacker would have root read access to each of the 3 machines, but
> the attacker would already have access to backups from each of the 3
> machines stored on the backup server itself so that's not really an
> issue.  I would also have the added inconvenience of using openvpn or
> ssh -R for my laptop so the backup server can pull from it through any
> router.
>
> What do you think guys?  Are push-style backups flawed and unacceptable?
>

No, it's not flawed, as long as the implementation is right: versioning and
deduplication.

With versioning, an attacker (or infiltrator, in this matter) might try to
taint the backup, but all she can do is just push a new version to the
server. You can recover your data by reverting to a prior version.

The deduplication part is only to save storage space. It's less necessary
if you have a robust versioning system that can categorize each push as
either canonical/perpetual/permanent or ephemeral/temporary. The system can
just discard old ephemeral pushes when storage becomes critical.

Rgds,

[-- Attachment #2: Type: text/html, Size: 2734 bytes --]