| 1 |
On Thu, 30 Apr 2009 14:18:33 +0600, Mike Kazantsev wrote: |
| 2 |
|
| 3 |
> The medium is regular sata2 hard drives with ext3 filesystem on a |
| 4 |
> dedicated backup machine with quite rusty debian (etch) linux. |
| 5 |
> Most backed-up systems (that I care about) are actually freebsd 6, the |
| 6 |
> rest are linux. Most stored backups are 20-60 GB. |
| 7 |
> |
| 8 |
> Main bottleneck here is the network - quite laggy 100 Mbps link, |
| 9 |
> because this backup server is quite far and isolated from the rest. |
| 10 |
> Also it's completely inaccessible from backed-up machines, aside from |
| 11 |
> reverse tunnels, which I rarely use as a dirty hacks. |
| 12 |
> And this link has tendency to go down every once in a while, |
| 13 |
> interrupting ongoing transfers. |
| 14 |
|
| 15 |
BackupPC should cope with this. It uses rsync over SSH, so only needs to |
| 16 |
transfer new/changed files, and will restart where it left off if the |
| 17 |
connection fails (this happens to me sometimes when I switch off my |
| 18 |
laptop while it is backing up and the backup just restarts the next |
| 19 |
morning). |
| 20 |
|
| 21 |
It is also space-efficient when backing up multiple machines, it uses |
| 22 |
hard links to store only one copy of each file, no matter how many |
| 23 |
machines have the same file. The lack of network access from the |
| 24 |
clients to the server would mean you couldn't access the web interface |
| 25 |
from the client you wished to restore to, but you could do that on the |
| 26 |
backup server if necessary. |
| 27 |
|
| 28 |
|
| 29 |
-- |
| 30 |
Neil Bothwick |
| 31 |
|
| 32 |
The mechanic said I had blown a seal. I said, `Just fix the damn thing and |
| 33 |
leave my private life out of it, OK?' |
Archives