rdiff-backup versions 0.2.x require Python version 2.1 or later, and versions 0.3.x and later require Python version 2.2 or later. If you don't know what version of python you are running, type in "python -V" from the shell. I'm sorry if this is inconvenient, but rdiff-backup uses generators, iterators, nested scoping, and static/class methods extensively, and these were only added in version 2.2.
If you have two versions of python installed, and running "python" defaults to an early version, you'll probably have to change the first line of the rdiff-backup script. For instance, you could set it to:
#!/usr/bin/env python2.2
There is no formal specification, but here is a rough description (settings are always cumulative, so 5 displays everything 4 does):
| 0 | No information given |
| 1 | Fatal Errors displayed |
| 2 | Warnings |
| 3 | Important messages, and maybe later some global statistics (default) |
| 4 | Some global settings, miscellaneous messages |
| 5 | Mentions which files were changed |
| 6 | More information on each file processed |
| 7 | More information on various things |
| 8 | All logging is dated |
| 9 | Details on which objects are moving across the connection |
Yes, apparently it is possible. First, follow Jason Piterak's instructions:
Subject: Cygwin rdiff-backup
From: Jason Piterak <Jason_Piterak@c-i-s.com>
Date: Mon, 4 Feb 2002 16:54:24 -0500 (13:54 PST)
To: rdiff-backup@keywest.Stanford.EDU
Hello all,
On a lark, I thought I would attempt to get rdiff-backup to work under
Windows98 under Cygwin. We have a number of NT/Win2K servers in the field
that I'd love to be backing up via rdiff-backup, and this was the start of
getting that working.
SUMMARY:
o You can get all the pieces for rdiff-backup working under Cygwin.
o The backup process works up to the point of writing any files with
timestamps.
... This is because the ':' character is reserved for Alternate Data
Stream (ADS) file designations under NTFS.
HOW TO GET IT WORKING (to a point, anyway):
o Install Cygwin
o Download the Python 2.2 update through the Cygwin installer and install.
o Download the librsync libraries from the usual place, but before
compiling...
o Cygwin does not use/provide glibc. Because of this, you have to repoint
some header files in the Makefile:
-- Make sure that you have /usr/include/inttypes.h
redirected to /usr/include/sys/types.h. Do this by:
create a file /usr/include/inttypes.h with the contents:
#include <sys/types.h>
o Put rdiff-backup in your PATH, as you normally would.
Then, whenever you use rdiff-backup to back up from a unix system to
Windows, use the --windows-mode switch. This
compensates for some windows file systems' inability to store hard
links, symlinks, device files, sockets, fifos, case sensitive
filenames, and filenames with colons (":") in them. (Note: device
files, symlinks, fifos, and sockets will simply be skipped, and hard
link information will not be recorded.)
If you are backing up one windows system to another, full --windows-mode is not necessary, but you'll still need --windows-time-format, which stops rdiff-backup from trying to make increment files with colons in them. Whichever --windows* option you use, remember to use the same one when restoring or listing that backup directory.
Yes, but there may be some issues installing librsync. See this
message from Gerd Knops:
Let's take an example. Suppose you ran
There may be a problem with rdiff-backup and Solaris' libthread.
Adding "ulimit -n unlimited" may fix the problem though. Here is a
post by Kevin Spicer on the subject:
rdiff-backup can be limited by the CPU, disk IO, or available
bandwidth, and the length of a session can be affected by the amount
of data, how much the data changed, and how many files are present.
That said, in the typical case the number/size of changed files is
relatively small compared to that of unchanged files, and rdiff-backup
is often either CPU or bandwidth bound, and takes time proportional to
the total number of files. Initial mirrorings will usually be
bandwidth or disk bound, and will take much longer than subsequent
updates.
To give two arbitrary data points, when I back up my personal HD
locally (about 9GB, 600000 files, maybe 50 MB turnover, 1.1Ghz athlon)
rdiff-backup takes about 35 minutes and is usually CPU bound. Another
user reports an rdiff-backup session takes about 3 hours (80GB, ~1mil
files, 2GB turnover) to back up remotely Tru64 -> linux.
Let's examine an example session statistics file:
StartTime and EndTime are measured in seconds since the epoch.
ElapsedTime is just EndTime - StartTime, the length of the
rdiff-backup session.
SourceFiles are the number of files found in the source directory,
and SourceFileSize is the total size of those files. MirrorFiles are
the number of files found in the mirror directory (not including the
rdiff-backup-data directory) and MirrorFileSize is the total size of
those files. All sizes are in bytes. If the source directory hasn't
changed since the last backup, MirrorFiles == SourceFiles and
SourceFileSize == MirrorFileSize.
NewFiles and NewFileSize are the total number and size of the files
found in the source directory but not in the mirror directory. They
are new as of the last backup.
DeletedFiles and DeletedFileSize are the total number and size of
the files found in the mirror directory but not the source directory.
They have been deleted since the last backup.
ChangedFiles are the number of files that exist both on the mirror
and on the source directories and have changed since the previous
backup. ChangedSourceSize is their total size on the source
directory, and ChangedMirrorSize is their total size on the mirror
directory.
IncrementFiles is the number of increment files written to the
rdiff-backup-data directory, and IncrementFileSize is their total
size. Generally one increment file will be written for every new,
deleted, and changed file.
TotalDestinationSizeChange is the number of bytes the destination
directory as a whole (mirror portion and rdiff-backup-data directory)
has grown during the given rdiff-backup session. This is usually
close to IncrementFileSize + NewFileSize - DeletedFileSize +
ChangedSourceSize - ChangedMirrorSize, but it also includes the space
taken up by the hardlink_data file to record hard links.
There is no internal rdiff-backup option to do this. However, the
--sleep-ratio option can limit overall resource usage, including
bandwidth. Also, external utilities such as cstream can be
used to monitor bandwidth explicitly. trevor@tecnopolis.ca writes:
Another option is to limit bandwidth at a lower (and perhaps more
appropriate) level. Adam Lazur mentions The Wonder Shaper.
The amount of memory rdiff-backup uses should not depend much on
the size of directories being processed. Keeping track of hard links
may use up memory, so if you have, say, hundreds of thousands of files
hard linked together, rdiff-backup may need tens of MB.
If rdiff-backup seems to be leaking memory, it is probably because
it is using an early version of librsync. librsync 0.9.5
leaks lots of memory. Version 0.9.5.1 should not leak and is
available from the rdiff-backup homepage.
From: Gerd Knops
Also, if you are backing up to a file system that is not case
sensitive you may need to use "--chars-to-quote A-Z". If you do use
--chars-to-quote, remember to use it with the same arguments when
restoring or listing incrementes.
rdiff-backup /usr /backup
and now realize that you don't want /usr/local backed up on /backup.
Next time you back up, you run
rdiff-backup --exclude /usr/local /usr /backup
so that /usr/local is no longer copied to /backup/usr/local.
However, old information about /usr/local is still present in
/backup/rdiff-backup-data/increments/usr/local. You could wait for
this information to expire and then run rdiff-backup with the
--remove-older-than option, or you could remove the increments
manually by typing:
rm -rf /backup/rdiff-backup-data/increments/usr/local
rm /backup/rdiff-backup-data/increments/usr/local.*.dir
Subject: RE: Crash report....still not^H^H^H working
From: "Spicer, Kevin"
StartTime 1028200920.44 (Thu Aug 1 04:22:00 2002)
EndTime 1028203082.77 (Thu Aug 1 04:58:02 2002)
ElapsedTime 2162.33 (36 minutes 2.33 seconds)
SourceFiles 494619
SourceFileSize 8535991560 (7.95 GB)
MirrorFiles 493797
MirrorFileSize 8521756994 (7.94 GB)
NewFiles 1053
NewFileSize 23601632 (22.5 MB)
DeletedFiles 231
DeletedFileSize 10346238 (9.87 MB)
ChangedFiles 572
ChangedSourceSize 86207321 (82.2 MB)
ChangedMirrorSize 85228149 (81.3 MB)
IncrementFiles 1857
IncrementFileSize 13799799 (13.2 MB)
TotalDestinationSizeChange 28034365 (26.7 MB)
Errors 0
rdiff-backup --remote-schema
'cstream -v 1 -t 10000 | ssh %s '\''rdiff-backup --server'\'' | cstream -t 20000'
'netbak@foo.bar.com::/mnt/backup' localbakdir
(must run from a bsh-type shell, not a csh type)
That would apply a limit in both directions [10000 bytes/sec outgoing,
20000 bytes/sec incoming]. I don't think you'd ever really want to do
this though as really you just want to limit it in one direction.
Also, note how I only -v 1 in one direction. You probably don't want
to output stats for both directions as it will confuse whatever script
you have parsing the output. I guess it wouldn't hurt for manual runs
however.
To only limit bandwidth in one directory, simply remove one of the
cstream commands. Two cstream caveats may be worth mentioning: