Re: [gentoo-user] {OT} backups... still backups....

[Michael Hampicke]

Am 01.07.2013 16:08, schrieb Grant:
>>>> There is no sacrifice, you are running rsync as root on the client
>>>> either way. Alternatively, you could run rsyncd on the client, which
>>>> avoids the need for the server to be able to run an SSH session.
>>>
>>> I think the sacrifice is that with the backuppc method, if someone
>>> breaks into the backup server they will have read(/write) access to
>>> the clients.  The method I'm describing requires more management if
>>> you have a lot of machines, but it doesn't have the aforementioned
>>> vulnerability.
>>>
>>> The rsyncd option is interesting.  If you don't want to restore
>>> directly onto the client, there are no SSH keys involved at all?
>>
>> Not even then, the server talks to the client in the same way for
>> restores as it does for backups, so it would still use rsyncd if you
>> wanted it to.
>
> Hmmm, now that I think about it, I guess the server accessing the
> client via rsyncd still provides the server with root read/write
> access to the client just like SSH keys.
>
>> I don't think it too unreasonable to assume that a machine with no ports
>> exposed to the Internet will not be compromised from the Internet.
>> Whereas a push approach requires that the server have open ports.
>
> Agreed, but this requires that the backup server is local to the admin
> which may not be possible.  openvpn requires open ports of course.
> There's also the possibility of a local break-in....
>
That' how we do it. The backuppc server is in our local lan, and only
accessible from local lan. It pulls backups from all our machines in
offsite data centers. To compromise our backuppc machine one would have
to physically break into our companies building.
But if somebody has physical access to the machine on which you store
your backups, you're screwed, no matter if you use push or pull backup :)