Re: [BackupPC-users] Howto backup BackupPC server

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ludovic Gele wrote:
<blockquote cite="mid...@ww..." type="cite">
  <pre wrap="">Selon Brien Dieterle <a class="moz-txt-link-rfc2396E" href="mailto:bri...@cg...">&lt;bri...@cg...&gt;</a>:

  </pre>
  <blockquote type="cite">
    <pre wrap="">I don't think another instance of backuppc would work "very well" for a 
number of reasons.  However, I think you could do well with copying the 
raw block device over netcat or ssh.  If you are using LVM for the 
backuppc data you could take a snapshot and not affect regular backups, 
otherwise you should stop backuppc and unmount the partition first (you 
are using a dedicated partition, right? ;-) )

Couple tips if you try this:  set the readahead on the block dev fairly 
high before you start dd (blockdev --setra 16384 /dev/device).   Then 
pipe it out with dd and compress it with lzop ( dd if=/dev/device bs=10M 
| lzop -1c |nc host port).  On the receiving end you'd run something 
like  nc -l -p port &gt;diskdump.  This is what I use for LAN, but for slow 
links you'd probably want more compression.  For good measure you might 
want to zero out the extra space on the drive before you dump it (dd 
if=/dev/zero of=blah bs=1M ; rm blah).

Of course, this would require quite a bit of disk space and would limit 
your backup intervals and retention policies...  Any other ideas, List?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Hi folks,

Why not drbd or unison?
 </pre>
</blockquote>
I think unison doesn't handle hard links and might have the same memory
problems as rsync.&nbsp; DRBD might actually be a good idea.&nbsp; However, just
using drbd incurs a small performance hit even when you're not
syncing.&nbsp; For offsite, you'd certainly want to use protocol A which
allows for inconsistency.&nbsp; However, I am not sure what would happen
over an extremely slow link (you can only seem to have a certain amount
of changes waiting on the sending side).&nbsp; Another option could be to
run the offsite system offline and only turn on the syncer during the
day when no backups are running-- however that might actually move a
lot of extra data to sync the entire chunks of the disk that were
modified. 
 
Looks like we're all waiting for <a
 href="http://rsync.samba.org/ftp/unpacked/rsync/NEWS">Rsync 3.0 </a>to
be released, which may or may not actually solve our problems :-) 
 
Oh, and it sounds like we're really talking about adding redundancy,
not "backups", which might imply having revisions, etc.&nbsp; If your pool
gets corrupted or deleted, you better know about it before your Rsync
job trashes your copy-- if you are using drbd you are already toast :-) 
 
So, I think the word is: don't bother.&nbsp; Use the archive features in
backuppc to archive your machines to USB or other offline media.&nbsp; :-) 
 
brien 
</body>
</html>