From 00893351a2b68273f577df9b655983e81a8a3104 Mon Sep 17 00:00:00 2001
From: owsla In general, rdiff-backup does not strive to make newer clients compatible
+with older servers (or vice versa). However, there is no intention to
+purposefully make different versions incompatible across the network -- changes
+are introduced primarily to fix bugs or introduce new features that cannot be
+implemented without breaking the network protocol. Furthermore, rdiff-backup
+does try to make it possible to read older archives. When running as a client, rdiff-backup checks the version of rdiff-backup
+running on the server, and prints a warning message if the two versions are
+different. If you have any problems with your backup, it is strongly
+recommended that you upgrade the older version before reporting any issues. Yes, although it is not a heavily tested configuration. Using the latest releases, such as
@@ -101,11 +120,21 @@ experience one of these common errors: If you're still having trouble backing up to a CIFS or smbfs mount, try searching the
mailing-list archives and then sending
@@ -116,7 +145,7 @@ further questions to the list.Table of contents
ValueError: Incorrect length of data produced
"?
touple index out of range
" mean?IO Error: CRC check failed
" mean?AssertionError: Bad index order
" mean?Questions and Answers
@@ -42,6 +46,21 @@ how much is required? What is the problem if rdiff-backup says
8 All logging is dated
+
+9 Details on which objects are moving across the connection
$ echo 0 > /proc/fs/cifs/LookupCacheEnabled
and then remounting the CIFS share.
- iocharset=
mount option. This
- happens because the server is using a codepage with only partial Unicode support and is not translating
- characters correctly. See the mount.cifs man page for more information. Using smbfs can also improve this
- situation since it has both an iocharset=
and a codepage=
option.
+ iocharset=
mount option. This happens
+ because the server is using a codepage with only partial Unicode support
+ and is not translating characters correctly. See the mount.cifs man page
+ for more information. Using smbfs can also improve this situation since it
+ has both an iocharset=
and a codepage=
option.
+ There is also an
+ entry in the Wiki about this.
+ mapchars
option to
+ the CIFS mount. At least one user has reported success when using this
+ option while mounting a NAS system via CIFS. See the mount.cifs man page
+ for more information.
Imagine you have a Linux directory with two files, "bar" and "BAR", and you copy them to a Mac system. You will
wind up with only one file (!) since HFS+ doesn't distinguish between the names, and the second file copied will
overwrite the first. Therefore, when rdiff-backup copies files from case-sensitive to case-insensitive filesystems, it escapes the uppercase characters (eg, "M" is replaced with ";077", and "F" with ";070") so that no filename
@@ -354,4 +383,44 @@ information, read the bash manpage
.bashrc
and .bash_profile
files.
In particular, this can happen if rdiff-backup was installed via Fink on a remote Mac OS X system. /sw/bin
is magically added to your $PATH
by the script /sw/bin/init.sh
when you login with an interative shell. Fink did this behind the scenes when you set it up. Simply add /sw/bin
to your path manually, or copy rdiff-backup to a directory that is in your $PATH
.
touple index out of range
" mean?
+
+If you see the error "tuple index out of range
" after running a command like:
+$ rdiff-backup -l /path/to/backup/rdiff-backup-data/
+then the solution is to simply remove the extra "rdiff-backup-data" from the end of the path. The list increments option, and others like it, take the path to the repository, not the path to the rdiff-backup-data directory. In the above example, you should run again with:
+$ rdiff-backup -l /path/to/backup
+If you get this error message for an unrelated reason, try contacting the mailing list.
IO Error: CRC check failed
" mean?
+
+This error message means that a
+Cyclic Redudancy
+Check failed during some operation, most likely while gzip'ing or
+un-gzip'ing a file. Possible causes of this error include an incomplete
+gzip operation, and hardware failure. A brute-force way to recover from this
+error is to remove the rdiff-backup-data directory. However, this will remove
+all of your past increments. A better approach may be to delete the particular
+file that is causing the problem. A command like:
+$ find rdiff-backup-data -type f -name \*.gz -print0 | xargs -0r gzip --test
+will find the failing file. For more information on this approach, see this
+mailing list post: http://lists.nongnu.org/archive/html/rdiff-backup-users/2007-11/msg00008.html.
AssertionError: Bad index order
" mean?
+
+If rdiff-backup fails with the message "AssertionError: Bad index order
," it could be because the files in a directory have changed while
+rdiff-backup is running. Possible ways of dealing with this situation include
+implementing filesystem snapshots using the volume manager, excluding the
+offending directory, or suspending the process that is changing the directory.
+After the text "Bad index order", the error messge will indicate which files
+have caused the problem.
+
If you get this message for an unreleated reason, try contacting the mailing +list.
+ +