| 1 |
>> > It's a lot more work and doesn't cover everything. One of the |
| 2 |
>> > advantages of a pull system like BackupPC is that the only work |
| 3 |
>> > needed on the client is adding the backuppc user's key to authorized |
| 4 |
>> > keys. Everything else is done by the server. If the server cannot |
| 5 |
>> > contact the client, or the connection is broken mid-backup, it tries |
| 6 |
>> > again. It also gives a single point of configuration. If you want to |
| 7 |
>> > change the backup plan fr all machines, you make one change on one |
| 8 |
>> > computer. |
| 9 |
>> |
| 10 |
>> If you have a crazy number of machines to back up, I could see |
| 11 |
>> sacrificing some security for convenience. Still I would think you |
| 12 |
>> could use something like puppet to have the best of both worlds. I |
| 13 |
>> have 5 machines and I think I can get it down to 3. |
| 14 |
> |
| 15 |
> There is no sacrifice, you are running rsync as root on the client |
| 16 |
> either way. Alternatively, you could run rsyncd on the client, which |
| 17 |
> avoids the need for the server to be able to run an SSH session. |
| 18 |
|
| 19 |
I think the sacrifice is that with the backuppc method, if someone |
| 20 |
breaks into the backup server they will have read(/write) access to |
| 21 |
the clients. The method I'm describing requires more management if |
| 22 |
you have a lot of machines, but it doesn't have the aforementioned |
| 23 |
vulnerability. |
| 24 |
|
| 25 |
The rsyncd option is interesting. If you don't want to restore |
| 26 |
directly onto the client, there are no SSH keys involved at all? |
| 27 |
|
| 28 |
>> > It works well, save work and minimises disk space usage, especially |
| 29 |
>> > with multiple similar clients. Preventing infiltration is simple as |
| 30 |
>> > you don't need to open it to the Internet at all, the backup server |
| 31 |
>> > can be completely stealthed and still do its job. |
| 32 |
>> |
| 33 |
>> Obviously the backup server has to be able to make outbound |
| 34 |
>> connections in order to pull so I think you're saying it could drop |
| 35 |
>> inbound connections, but then how could you talk to it? Do you mean a |
| 36 |
>> local backup server? |
| 37 |
> |
| 38 |
> Yes, you talk to the server over the LAN, or a VPN. There need be no way |
| 39 |
> of connecting to it from outside of your LAN. |
| 40 |
|
| 41 |
To me it seems presumptuous to be sure a particular machine will never |
| 42 |
be infiltrated to the degree that you're OK with such an infiltration |
| 43 |
giving read(/write) access on every client to the infiltrator. |
| 44 |
|
| 45 |
- Grant |
Archives