1 |
On Friday, August 19, 2011 10:35:10 AM Grant wrote: |
2 |
> >> >> I'm setting up an automated rdiff-backup system and I'm stuck |
3 |
> >> >> between |
4 |
> >> >> pushing the backups to the backup server, and pulling the |
5 |
> >> >> backups to |
6 |
> >> >> the backup server. If I push, I have to allow read/write access |
7 |
> >> >> of my backups via SSH keys. If I pull, I have to enable root |
8 |
> >> >> logins on each system to be backed-up, allow root read access |
9 |
> >> >> of each system via SSH keys, and I have to deal with openvpn or |
10 |
> >> >> ssh -R so my laptop can back up from behind foreign routers. |
11 |
> >> >> The conventional wisdom online seems to indicate pulling is |
12 |
> >> >> better, but pushing seems like it might be better to me. Do |
13 |
> >> >> you push or pull? |
14 |
> >> > |
15 |
> >> > I would push, to be honest. |
16 |
> >> |
17 |
> >> What can be done about the fact that any attacker who can break into a |
18 |
> >> system and wipe it out can also wipe out its backups? That negates |
19 |
> >> one of the reasons for making the backups in the first place. |
20 |
> > |
21 |
> > True, except if, after a backup is finished, you move the actual backup |
22 |
> > to a different location. (Or you backup the backup server) |
23 |
> |
24 |
> I do back up the backup server to another system via rsync, but if the |
25 |
> backups on the backup server are wiped out, rsync will wipe them out |
26 |
> on the other system too. |
27 |
|
28 |
Why not use a different backup tool that doesn't have this possible problem? |
29 |
Rsync will clear the target is the source is emptied as well. Not sure if this |
30 |
can be prevented. |
31 |
|
32 |
> > I store all important files on my server and the backups there can not |
33 |
> > be |
34 |
> > accessed from the fileserver itself. (That backup is done in "pull" mode |
35 |
> > every night.) |
36 |
> |
37 |
> I thought you were in favor of "pushing"? How do you back up to a |
38 |
> system that can't access the backups? |
39 |
|
40 |
I am, when it comes to backing up desktops. The server is actually a xen-host |
41 |
with multiple xen-domains running on it. |
42 |
|
43 |
I found it easier to have the host determine the backups. The sequence of |
44 |
steps is basically as follows: |
45 |
1) host tells domain to stop service(s) |
46 |
2) host tells domain to unmount filesystem |
47 |
3) hosts disconnects filesystem from domain |
48 |
4) host creates snapshot (LVM) |
49 |
5) host reconnect filesystem to domain |
50 |
6) host tells domain to remount filesystem |
51 |
7) host tells domain to stop service(s) |
52 |
8) host backs up snapshot |
53 |
9) host deletes snapshot |
54 |
|
55 |
I couldn't do a push-system for the virtual machines as I didn't want to |
56 |
expose the host. |
57 |
|
58 |
> >> Should private SSH keys be excluded from the backup? Should anything |
59 |
> >> else be excluded? |
60 |
> > |
61 |
> > When a host is compromised, the corresponding entries in the |
62 |
> > "authorized_keys" should be removed from all other servers/hosts. This |
63 |
> > will make those private keys useless. |
64 |
> |
65 |
> So it's OK to back up a private key to another system? I just want to |
66 |
> make sure I'm not breaking a "good admin" rule by doing this. |
67 |
|
68 |
Yes, I don't see any problem with that. |
69 |
If the backup-server is compromised via a compromised other system, the keys |
70 |
on that system are compromised already anyway. |
71 |
|
72 |
I don't have private keys without passphrase apart from the one the host uses |
73 |
to send commands to the virtual machines. And the host can't be accessed by |
74 |
remote. |
75 |
|
76 |
-- |
77 |
Joost |