>> > It's a lot more work and doesn't cover everything. One of the
>> > advantages of a pull system like BackupPC is that the only work
>> > needed on the client is adding the backuppc user's key to authorized
>> > keys. Everything else is done by the server. If the server cannot
>> > contact the client, or the connection is broken mid-backup, it tries
>> > again. It also gives a single point of configuration. If you want to
>> > change the backup plan fr all machines, you make one change on one
>> > computer.
>>
>> If you have a crazy number of machines to back up, I could see
>> sacrificing some security for convenience.  Still I would think you
>> could use something like puppet to have the best of both worlds.  I
>> have 5 machines and I think I can get it down to 3.
>
> 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?

>> > It works well, save work and minimises disk space usage, especially
>> > with multiple similar clients. Preventing infiltration is simple as
>> > you don't need to open it to the Internet at all, the backup server
>> > can be completely stealthed and still do its job.
>>
>> Obviously the backup server has to be able to make outbound
>> connections in order to pull so I think you're saying it could drop
>> inbound connections, but then how could you talk to it?  Do you mean a
>> local backup server?
>
> Yes, you talk to the server over the LAN, or a VPN. There need be no way
> of connecting to it from outside of your LAN.

To me it seems presumptuous to be sure a particular machine will never
be infiltrated to the degree that you're OK with such an infiltration
giving read(/write) access on every client to the infiltrator.

- Grant

Reply via email to