| 1 |
>> > There is no sacrifice, you are running rsync as root on the client |
| 2 |
>> > either way. Alternatively, you could run rsyncd on the client, which |
| 3 |
>> > avoids the need for the server to be able to run an SSH session. |
| 4 |
>> |
| 5 |
>> I think the sacrifice is that with the backuppc method, if someone |
| 6 |
>> breaks into the backup server they will have read(/write) access to |
| 7 |
>> the clients. The method I'm describing requires more management if |
| 8 |
>> you have a lot of machines, but it doesn't have the aforementioned |
| 9 |
>> vulnerability. |
| 10 |
>> |
| 11 |
>> The rsyncd option is interesting. If you don't want to restore |
| 12 |
>> directly onto the client, there are no SSH keys involved at all? |
| 13 |
> |
| 14 |
> Not even then, the server talks to the client in the same way for |
| 15 |
> restores as it does for backups, so it would still use rsyncd if you |
| 16 |
> wanted it to. |
| 17 |
|
| 18 |
Hmmm, now that I think about it, I guess the server accessing the |
| 19 |
client via rsyncd still provides the server with root read/write |
| 20 |
access to the client just like SSH keys. |
| 21 |
|
| 22 |
> I don't think it too unreasonable to assume that a machine with no ports |
| 23 |
> exposed to the Internet will not be compromised from the Internet. |
| 24 |
> Whereas a push approach requires that the server have open ports. |
| 25 |
|
| 26 |
Agreed, but this requires that the backup server is local to the admin |
| 27 |
which may not be possible. openvpn requires open ports of course. |
| 28 |
There's also the possibility of a local break-in.... |
| 29 |
|
| 30 |
- Grant |
Archives