1 |
On Mon, 1 Jul 2013 01:39:56 -0700, Grant wrote: |
2 |
|
3 |
> > Yes, but with push you have to secure each machine whereas with pull |
4 |
> > backups it's only the server to secure. And you'd still need to grant |
5 |
> > access to the server from the clients, which could be escalated. With |
6 |
> > backuppc, the server does not need to be accessible from the Internet |
7 |
> > at all, all requests are outgoing. If the server machine serves other |
8 |
> > purposes and needs to be net-accessible, run the backup server in a |
9 |
> > chroot or VM. |
10 |
> |
11 |
> I'm planning to rsync --fake-super the important files from each |
12 |
> client to a particular folder on the backup server as an unprivileged |
13 |
> user and then have the backup server run rdiff-backup locally to |
14 |
> maintain a history of those files. |
15 |
|
16 |
How does that work with files that aren't world-readable? |
17 |
|
18 |
> authorized_keys on the server |
19 |
> would restrict the clients to a particular rsync command in a |
20 |
> particular directory. That way if the backup server is infiltrated, |
21 |
> the clients aren't exposed in any way, and if a client is infiltrated, |
22 |
> the only extra exposure is the rsync'ed copy of the files on the |
23 |
> server which isn't a real vulnerability because of the rdiff-backup |
24 |
> history. I'd also like to have a secondary backup server pull those |
25 |
> same rsync'ed files from the primary backup server and run its own |
26 |
> rdiff-backup repository on them. That way all copies of any system's |
27 |
> backups are never made vulnerable by the break-in of a single system. |
28 |
> |
29 |
> Doesn't that compare favorably to a layout like backuppc's? |
30 |
|
31 |
It's a lot more work and doesn't cover everything. One of the advantages |
32 |
of a pull system like BackupPC is that the only work needed on the client |
33 |
is adding the backuppc user's key to authorized keys. Everything else is |
34 |
done by the server. If the server cannot contact the client, or the |
35 |
connection is broken mid-backup, it tries again. It also gives a single |
36 |
point of configuration. If you want to change the backup plan fr all |
37 |
machines, you make one change on one computer. |
38 |
|
39 |
It works well, save work and minimises disk space usage, especially with |
40 |
multiple similar clients. Preventing infiltration is simple as you don't |
41 |
need to open it to the Internet at all, the backup server can be |
42 |
completely stealthed and still do its job. |
43 |
|
44 |
|
45 |
-- |
46 |
Neil Bothwick |
47 |
|
48 |
Better to understand a little than to misunderstand a lot. |