Branches
Comments
[»]
vis a vi rsync?
by Benjamin Smith - Dec 14th 2005 00:27:25
Yeah, it's great. No problem, rsync is great, too! So, is this better than
rsync? If so, why? Is it much better than rsync? Again, why?
I wrote Backup Buddy http://www.effortlessis.com/backupbuddy/ as a backup
solution using rsync and PHP. I coordinate TB of data with this - is this
better?
If it is better, why?
[reply]
[top]
[»]
Re: vis a vi rsync?
by Ben Escoto - Dec 15th 2005 12:00:05
I think rsync and rdiff-backup both have strengths and weaknesses.
rsync is often significantly faster than rdiff-backup, while rdiff-backup
can use much less memory and be less disk intensive on large directories
because it does not build the entire filelist ahead of time. And I have
had some people tell me that they couldn't get rsync to work on their
system, but rdiff-backup worked fine (I'm sure the reverse is also
true).
Maybe the biggest feature that rdiff-backup has that rsync doesn't
(besides the whole incremental backup thing) is support for various
optional filesystem features, and the ability to back them up to a
filesystem of a different type.
For instance, rdiff-backup can back up a filesystem that has ACLs,
extended attributes, and various owners/groups, to a filesystem that
doesn't have ACLs, EAs, or root permissions. With rsync you would lose
that information, including all ownership. With rdiff-backup, everything
will be preserved when you restore.
Rsync-based programs like your backupbuddy will probably inherit most
of the strengths/weaknesses of rsync. Also rdiff-backup will in general
use less disk space because it compresses file changes over time. Also
newer versions of rdiff-backup keep SHA1 checksums of all regular files
around, which can help with security auditing or checking the integrity of
existing backups.
But anyway I'm sure both programs have their pros and cons, and I
encourage anyone reading this to test both out for themselves.
[reply]
[top]
[»]
Handy
by Scott Lamb - May 2nd 2005 22:06:38
Networked, incremental backups are definitely the way to go.
Sending things to another machine is much easier and more
reliable than tape. And it sucks to pull a backup file only to
discover you'd screwed it up before making a backup.
rdiff-backup avoids these problems.
It's also the only such tool I've seen that can handle Mac
OS X resource forks. (With 0.13.2 or better, IIRC.) These are
more important than you'd think - Quicken, for example, stores
important data in them.
[reply]
[top]
[»]
rdiff-backup has SERIOUS PROBLEMS
by plausible deniability - Mar 19th 2005 09:05:16
I've run rdiff-backup on a handful of systems, backing up on the same
system, and remotely.
When a backup fails, rdiff essentially gives up responsibility for your
backup's integrity. It will not preserve an operable, *usable* system
state. It then becomes the admin's responsibility to *manually repair* the
metadata which controls rdiff's behavior.
If you cannot successfully make those repairs, admins are advised in the
documentation to *delete* the entire backup and start from scratch!
This is unacceptable. For rdiff-backup to become a serious and useful
project, it needs to proactively take action when a failure occurs! For
example, when there are network connectivity problems, rdiff-backup gives
up and the backup is considered failed. *Further attempts* to backup will
be rejected until you manually revert the metadata!
In other words: Don't go on vacation! When you've put your faith in
rdiff-backup, and it fails while you're on that desert island, it will let
you down: subsequent backups will fail too.
rsync is a much better solution, although you lose the sub-file increment
capability of the rdiff algorithm. But disk space is cheap, and backups
that repeatedly fail can cost you your job.
--
-plaus
[reply]
[top]
[»]
Re: rdiff-backup has SERIOUS PROBLEMS
by Ben Escoto - Mar 25th 2005 21:38:20
Hi, I'm sorry your experiences with rdiff-backup were so bad.
rdiff-backup's error policy is stated here.
As it says, rdiff-backup does make an effort to recover from different
types of errors in different ways, to leave the database in a consistent
state in the face of unrecoverable errors, and reverse failed backup
sessions (effecting a kind of atomicity between sessions).
Unfortunately, rdiff-backup archives can get corrupted (e.g. by disk
errors or bugs in rdiff-backup) beyond the program's ability to
automatically repair them. In these cases manual repair is necessary. But
this is true of any backup program. Just a reminder, if you are using the
program for something important, please use the stable version. The
current unstable version is really old and doesn't include many CVS fixes.
And anyway it's unstable.
Anyway, how rdiff-backup responds to network problems is testable..
Start a session and simulate a failure by killing the client or server, or
by taking down the network connection. Then see what happens to the next
session.
[reply]
[top]
[»]
WOW!
by Dave W - Mar 17th 2005 09:18:30
I have been using rdiff-backup with great success for about 2 years. It is
by far the best backup program that I found after doing lots of looking.
Handles backing up *nix filesystems to windows, and retains all
"special" info (like ownership and permissions etc) in a separate
file, so full backup can be done. Only transmits differences of changed
files, so it's extremely efficient, AND it allows backup over ssh, so files
stay secure when backing up over the internet from one *nix machine to
another! Reverse incremental means you can just copy the most recently
backed up version of a file from the backup directory, and if you want to
restore from a previous backup, you can mess with the command line
switches. Holy Toledo.. Ben Escoto, you're a genius. A must have for
anyone and everyone! It's so good that I'm going to cry. They ought to
make this standard with any linux distribution.
--
Dave W
[reply]
[top]
[»]
Great great tool
by Olivier L. Müller - Mar 2nd 2003 15:52:46
Using it daily (well, nightly) to backup some servers on a backup server
and it works very well :-)
[reply]
[top]
|
