1 |
On Thursday, August 18, 2011 06:51:32 PM Grant wrote: |
2 |
> >> I'm setting up an automated rdiff-backup system and I'm stuck between |
3 |
> >> pushing the backups to the backup server, and pulling the backups to |
4 |
> >> the backup server. If I push, I have to allow read/write access of my |
5 |
> >> backups via SSH keys. If I pull, I have to enable root logins on each |
6 |
> >> system to be backed-up, allow root read access of each system via SSH |
7 |
> >> keys, and I have to deal with openvpn or ssh -R so my laptop can back |
8 |
> >> up from behind foreign routers. The conventional wisdom online seems |
9 |
> >> to indicate pulling is better, but pushing seems like it might be |
10 |
> >> better to me. Do you push or pull? |
11 |
> > |
12 |
> > I would push, to be honest. |
13 |
> |
14 |
> What can be done about the fact that any attacker who can break into a |
15 |
> system and wipe it out can also wipe out its backups? That negates |
16 |
> one of the reasons for making the backups in the first place. |
17 |
|
18 |
True, except if, after a backup is finished, you move the actual backup to a |
19 |
different location. (Or you backup the backup server) |
20 |
|
21 |
I store all important files on my server and the backups there can not be |
22 |
accessed from the fileserver itself. (That backup is done in "pull" mode every |
23 |
night.) |
24 |
|
25 |
> Should private SSH keys be excluded from the backup? Should anything |
26 |
> else be excluded? |
27 |
|
28 |
When a host is compromised, the corresponding entries in the "authorized_keys" |
29 |
should be removed from all other servers/hosts. This will make those private |
30 |
keys useless. |
31 |
|
32 |
If you protect them with a passphrase, the private keys are not usable in any |
33 |
case. But this will require the backups to be started manually to allow you to |
34 |
enter the passphrase. |
35 |
Or you unlock the passphrase in memory and use ssh-agent for that. |
36 |
|
37 |
-- |
38 |
Joost |