-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathFAQ.html
455 lines (427 loc) · 27.8 KB
/
FAQ.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>rdiff-backup FAQ</title>
</head>
<body>
<h1>rdiff-backup FAQ</h1>
<!-- #bbpragma doctype="-//W3C//DTD XHTML 1.0 Strict//EN" root_element="body" -->
<h3><a name="ToC3">Table of contents</a></h3>
<ol><li><a href="#verbosity">What do the different verbosity levels mean?</a></li>
<li><a href="#compatible">Is rdiff-backup backwards compatible?</a></li>
<li><a href="#windows">Does rdiff-backup run under Windows?</a></li>
<li><a href="#OSX">Does rdiff-backup run under Mac OS X?</a></li>
<li><a href="#cifs">Can I backup files to a CIFS or smbfs mount?</a></li>
<li><a href="#case_insensitive">Help! Why do all my filenames now look like ;077y;070ile ?!</a></li>
<li><a href="#remove_dir">My backup set contains some files that I just realized I don't want/need backed up. How do I remove them from the backup volume to save space?</a></li>
<li><a href="#solaris">Does rdiff-backup work under Solaris?</a></li>
<li><a href="#speed">How fast is rdiff-backup? Can it be run on large
data sets?</a></li>
<li><a href="#statistics">What do the various fields mean in the
session statistics and directory statistics files?</a></li>
<li><a href="#bwlimit">Is there some way to limit rdiff-backup's
bandwidth usage, as in rsync's --bwlimit option?</a></li>
<li><a href="#leak">How much memory should rdiff-backup use? Is there a
memory leak?</a></li>
<li><a href="#dir_not_empty">I use NFS and keep getting some error that includes "OSError: [Errno 39] Directory not empty"</a></li>
<li><a href="#regress_failure">For some reason rdiff-backup failed
while backing up. Now every time it runs it says "regressing
destination" and then fails again. What should I do?</a></li>
<li><a href="#free_space">Where does rdiff-backup need free space and
how much is required? What is the problem if rdiff-backup says
"<code>ValueError: Incorrect length of data produced</code>"?</a></li>
<li><a href="#librsync_bug">What does "internal error: job made no progress" mean?</a></li>
<li><a href="#path">Why does rdiff-backup say it's not in my $PATH? It is when I login!</a></li>
<li><a href="#touple">What does "<code>touple index out of range</code>" mean?</a></li>
<li><a href="#crc">What does "<code>IO Error: CRC check failed</code>" mean?</a></li>
<li><a href="#badindex">What does "<code>AssertionError: Bad index order</code>" mean?</a></li>
<li><a href="#utc">How can rdiff-backup use UTC as the timzeone?</a></li>
</ol>
<h3><a name="ToC4">Questions and Answers</a></h3>
<ol>
<li><strong><a name="verbosity">What do the different verbosity levels mean?</a></strong>
<p>There is no formal specification, but here is a rough description
(settings are always cumulative, so 5 displays everything 4 does):</p>
<table cellspacing="10" summary="">
<tr><td>0</td><td>No information given</td></tr>
<tr><td>1</td><td>Fatal Errors displayed</td></tr>
<tr><td>2</td><td>Warnings</td></tr>
<tr><td>3</td><td>Important messages, and maybe later some global statistics (default)</td></tr>
<tr><td>4</td><td>Some global settings, miscellaneous messages</td></tr>
<tr><td>5</td><td>Mentions which files were changed</td></tr>
<tr><td>6</td><td>More information on each file processed</td></tr>
<tr><td>7</td><td>More information on various things</td></tr>
<tr><td>8</td><td>All logging is dated</td></tr>
<tr><td>9</td><td>Details on which objects are moving across the connection</td></tr>
</table>
</li>
<li><strong><a name="compatible">Is rdiff-backup backwards compatible?</a></strong>
<p>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.</p>
<p>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.</p>
</li>
<li><strong><a name="windows">Does rdiff-backup run under Windows?</a></strong>
<p>Yes, although it is not a heavily tested configuration. Rdiff-backup can be run as a native Windows application or under Cygwin. To run as a native Windows application, simply download the provided .exe binary. To setup remote operation, you will also need an SSH client, such as <a href="http://www.chiark.greenend.org.uk/~sgtatham/putty/">Putty</a> or <a href="http://www.ssh.com">SSH Secure Shell</a>. See the Wiki for more details on <a href="http://wiki.rdiff-backup.org/wiki/index.php/BackupFromWindowsToLinux">remote operation under native Windows</a>. Dave Kempe has also made some older .exe versions <a href="http://solutionsfirst.com.au/~dave/backup/">available for download</a>.</p>
<p>If you wish to run rdiff-backup under Cygwin, use at least version 1.1.12. The setup under Cygwin is the same as under other Unix-like operating systems. From the Cygwin installer you will need Python 2.2 or higher (under Interpreters), autoconf, automake, binutils, gcc, make, and patchutils (all under Devel). Then you will need to compile and install librsync, which can be downloaded <a href="https://sourceforge.net/project/showfiles.php?group_id=56125">from Sourceforge</a>. Finally, you can compile and install rdiff-backup using the usual instructions.</p>
<p>Although some Windows filesystems lack features like FIFOs, case
sensitive filenames, or files with colons (":") in them, all of these situations should
be autodetected and compensated for by rdiff-backup.</p>
<p>If you would like more detailed instructions for compiling and installing rdiff-backup on Cygwin, you can read this blog entry: <a href="http://katastrophos.net/andre/blog/?p=19">http://katastrophos.net/andre/blog/?p=19</a>. Note: The patch that the blog suggests that you download is no longer necessary starting with version 1.1.8 of rdiff-backup.</p>
</li>
<li><strong><a name="OSX">Does rdiff-backup run under Mac OS X?</a></strong>
<p>Yes, quite a few people seem to be using rdiff-backup under Mac OS
X. rdiff-backup can also backup resource forks and other Mac OS X metadata
to a traditional unix filesystem, which is can be a handy feature for Mac
users. When rdiff-backup is used to do the restore, all of the metadata is
recovered from rdiff-backup's storage.</p>
<p>The easiest option is probably to use Fink <a
href="http://fink.sourceforge.net/">http://fink.sourceforge.net/</a>,
which can install rdiff-backup automatically for you. With Fink, you
should install the <code>librsync</code>, <code>librsync-shlibs</code>,
<code>python25</code>, <code>python25-shlibs</code>, <code>xattr-py25</code>,
and <code>rdiff-backup</code> packages. Another option is DarwinPorts
<a href="http://www.macports.org/">http://www.macports.org/</a>, for which
you should install the <code>py-xattr</code> and <code>rdiff-backup</code> packages.</p>
<p>If you want to build rdiff-backup yourself, you should be able to build
librsync and rdiff-backup using the standard Unix instructions.
You can also see this message from Gerd Knops:</p>
<pre>From: Gerd Knops <[email protected]>
Date: Thu, 3 Oct 2002 03:56:47 -0500 (01:56 PDT)
[parts of original message deleted]
these instructions build it fine with all tests running OK
(librsync-0.9.5.1 on OS X 10.2.1):
aclocal
autoconf
automake --foreign --add-missing
env CFLAGS=-no-cpp-precomp ./configure
make
make install</pre>
<p>An important note if you use the Apple-provided version of Python: Apple's version
of Python will install rdiff-backup in something like
<code>/System/Library/Frameworks/Python.framework/Versions/Current/bin/rdiff-backup</code> and <code>rdiff-backup</code>
will not be in your <code>$PATH</code>. You can copy rdiff-backup out of this folder and into
someplace reasonable like <code>/usr/bin</code> or another directory in your <code>$PATH</code> to use it. For
a full explanation of why this happens see this post to the mailing list:
<a href="http://lists.nongnu.org/archive/html/rdiff-backup-users/2007-06/msg00107.html">http://lists.nongnu.org/archive/html/rdiff-backup-users/2007-06/msg00107.html</a>.</p>
</li>
<li><strong><a name="cifs">Can I backup files to a CIFS or smbfs mount?</a></strong>
<p>You can certainly try! Using a CIFS or smbfs mount as the mirror directory has been troublesome for
some users because of the wide variety of Samba configurations. If possible, the best solution is always
to use rdiff-backup over SSH in the default configuration. Using rdiff-backup in the default configuration
is also guaranteed to be faster because there is lower network utilization. Rdiff-backup uses
the rsync algorithm to minimize the amount of bandwidth consumed. By using smbfs or CIFS, the complete file
is transferred over the network.</p>
<p>Under both Linux and Mac OS X, smbfs seems to be working quite well. However, it has a 2 GB file limit and is
deprecated on Linux. CIFS users sometimes experience one of these common errors:</p>
<ul>
<li>rdiff-backup fails to run, printing an exception about "<code>assert not upper_a.lstat()</code>" failing.
This can be resolved by unmounting the share, running the following command as root:<br>
<code>$ echo 0 > /proc/fs/cifs/LookupCacheEnabled</code><br>
and then remounting the CIFS share.<br><br></li>
<li>If filenames in the mirror directory have some characters transformed
to a '?' instead of remaining the expected Unicode character, you will
need to adjust the <code>iocharset=</code> 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 <code>iocharset=</code> and a <code>codepage=</code> option.
There is also an
<a href="http://wiki.rdiff-backup.org/wiki/index.php/BackingUpUnicodeToSmbfsMount">entry in the Wiki</a> about this.<br><br>
</li>
<li>If you have trouble with filenames containing a colon ':', or another
reserved Windows character, try using the <code>mapchars</code> 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.<br><br></li>
<li>Other CIFS mount options which may be helpful include <code>nocase</code>,
<code>directio</code>, and <code>sfu</code>. Also, try changing the value of
<code>/proc/fs/cifs/LinuxExtensionsEnabled</code> (requires remount). A user
with a DroboShare reported that <code>-o mapchars,nocase,directio</code>
worked for that NAS appliance.</li>
</ul>
<p>If you're still having trouble backing up to a CIFS or smbfs mount, try searching the
<a href="http://lists.gnu.org/archive/html/rdiff-backup-users/">mailing-list archives</a> and then sending
further questions to the list.</p>
</li>
<li><strong><a name="case_insensitive">Help! Why do all my filenames now look like ;077y;070ile ?!</a></strong>
<p>When backing up from a case-sensitive filesystem to a case-insensitive filesystem (such as Mac's HFS+ or
Windows's FAT32 or NTFS), rdiff-backup escapes uppercase characters in filenames to make sure that no files
are accidentally overwritten. When a filesystem is case-preserving but case-insensitive, it means that it
remembers that a file is named "Foo" but doesn't distinguish between "Foo", "foo", "foO", "fOo", etc. However,
filesystems such as Linux's ext3 do treat these names as separate files.</p>
<p>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
conflicts occur. Upon restore (from the Mac backup server to the Linux system), the filenames are unquoted and
you will get "MyFile" back.</p>
</li>
<li><strong><a name="remove_dir">My backup set contains some files that I just realized I
don't want/need backed up. How do I remove them from the backup
volume to save space?</a></strong>
<p>The only official way to remove files from an rdiff-backup
repository is by letting them expire using the --remove-older-than
option. Deleting increments from the rdiff-backup-data directory will
prevent you from recovering those files, but shouldn't prevent the
rest of the repository from being restored.</p>
</li>
<li><strong><a name="solaris">Does rdiff-backup work under Solaris?</a></strong>
<p>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:</p>
<pre>Subject: RE: Crash report....still not^H^H^H working
From: "Spicer, Kevin" <[email protected]>
Date: Sat, 11 May 2002 23:36:42 +0100
Quick mail to follow up on this..
My rdiff backup (on Solaris 2.6 if you remember) has now worked
reliably for nearly two weeks after I added...
ulimit -n unlimited
to the start of my cron job and created a wrapper script on the remote
machine which looked like this...
ulimit -n unlimited
rdiff-backup --server
exit
And changed the remote schema on the command line of rdiff-backup to
call the wrapper script rather than rdiff-backup itself on the remote
machine. As for the /dev/zero thing I've done a bit of Googleing and
it seems that /dev/zero is used internally by libthread on Solaris
(which doesn't really explain why its opening more than 64 files - but
at least I think I've now got round it).
</pre>
</li>
<li><strong><a name="speed">How fast is rdiff-backup? Can it be run on large
data sets?</a></strong>
<p>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.</p>
<p>To give one arbitrary data point, when I back up my personal HD
locally (about 36GB, 530000 files, maybe 500 MB turnover, Athlon 2000,
7200 IDE disks, version 0.12.2) rdiff-backup takes about 15 minutes
and is usually CPU bound.</p>
</li>
<li><strong><a name="statistics">What do the various fields mean in the
session statistics and directory statistics files?</a></strong>
<p>Let's examine an example session statistics file:</p>
<pre>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</pre>
<p>StartTime and EndTime are measured in seconds since the epoch.
ElapsedTime is just EndTime - StartTime, the length of the
rdiff-backup session.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</li>
<li><strong><a name="bwlimit">Is there some way to limit rdiff-backup's
bandwidth usage, as in rsync's --bwlimit option?</a></strong>
<p>There is no internal rdiff-backup option to do this. However,
external utilities such as <a
href="http://www.cons.org/cracauer/cstream.html">cstream</a> can be
used to monitor bandwidth explicitly. [email protected]
writes:</p>
<pre>rdiff-backup --remote-schema
'cstream -v 1 -t 10000 | ssh %s '\''rdiff-backup --server'\'' | cstream -t 20000'
'[email protected]::/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.</pre>
<p>To only limit bandwidth in one directory, simply remove one of the
cstream commands. Two cstream caveats may be worth mentioning:</p>
<ol> <li>Because cstream is limiting the uncompressed data heading
into or out of ssh, if ssh compression is turned on, cstream may be
overly restrictive.</li>
<li>cstream may be "bursty", limiting average bandwidth but allowing
rdiff-backup to exceed it for significant periods.</li>
</ol>
<p>Another option is to limit bandwidth at a lower (and perhaps more
appropriate) level. Adam Lazur mentions <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a>.</p>
</li>
<li><strong><a name="leak">How much memory should rdiff-backup use? Is there a
memory leak?</a></strong>
<p>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.</p>
<p>If rdiff-backup seems to be leaking memory, it is probably because
it is using an early version of librsync. <strong>librsync 0.9.5
leaks lots of memory.</strong> Later versions should not leak and are
available from the <a href="https://sourceforge.net/projects/librsync/">librsync homepage</a>.</p>
</li>
<li><strong><a name="dir_not_empty">I use NFS and keep getting some error that includes "OSError: [Errno 39] Directory not empty"</a></strong>
<p>Several users have reported seeing errors that contain lines like
this:</p>
<pre>File "/usr/lib/python2.2/site-packages/rdiff_backup/rpath.py",
line 661, in rmdir
OSError: [Errno 39] Directory not empty:
'/nfs/backup/redfish/win/Program Files/Common Files/GMT/Banners/11132'
Exception exceptions.TypeError: "'NoneType' object is not callable"
in <bound method GzipFile.__del__ of</pre>
<p>All of these users were backing up onto NFS (Network File System).
I think this is probably a bug in NFS, although tell me if you know
how to make rdiff-backup more NFS-friendly. To avoid this problem,
run rdiff-backup locally on both ends instead of over NFS. This
should be faster anyway.</p>
</li>
<li><strong><a name="regress_failure">For some reason rdiff-backup failed
while backing up. Now every time it runs it says "regressing
destination" and then fails again. What should I do?</a></strong>
<p>Firstly, this shouldn't happen. If it does, it indicates a
corrupted destination directory, a bug in rdiff-backup, or some other
serious recurring problem.</p>
<p>However, here is a workaround that you might want to use, even
though it probably won't solve the underlying problem: In the
destination's rdiff-backup-data directory, there should be two
"current_mirror" files, for instance:</p>
<pre>current_mirror.2003-09-07T16:43:00-07:00.data
current_mirror.2003-09-08T04:22:01-07:00.data</pre>
<p>Delete the one with the earlier date. Also move the mirror_metadata
file with the later date out of the way, because it probably didn't
get written correctly because that session was aborted:</p>
<pre>mv mirror_metadata.2003-09-08T04:22:01-07:00.snapshot.gz aborted-metadata.2003-09-08T04:22:01-07:00.snapshot.gz</pre>
<p>The next time rdiff-backup runs it won't try regressing the
destination. Metadata will be read from the file system, which may
result in some extra files being backed up, but there shouldn't be any
data loss.</p>
</li>
<li><strong><a name="free_space">Where does rdiff-backup need free
space and how much is required? What is the problem when rdiff-backup
says "<code>ValueError: Incorrect length of data
produced</code>"?</a></strong>
<p>When backing up, rdiff-backup needs free space in the mirror
directory. The amount of free space required is usually a bit more
than the size of the file getting backed up, but can be as much as
twice the size of the current file. For instance, suppose you ran
<code>rdiff-backup foo bar</code> and the largest file,
<code>foo/largefile</code>, was 1GB. Then rdiff-backup would need
1+GB of free space in the <code>bar</code> directory.</p>
<p>When restoring or regressing, rdiff-backup needs free space in the default temp
directory. Under unix systems this is usually the <code>/tmp</code>
directory. The temp directory that rdiff-backup uses can be set using the
<code>--tempdir</code> and <code>--remote-tempdir</code> options available
in versions 1.1.13 and newer. See the entry for <code>tempfile.tempdir</code> in the <a
href="http://www.python.org/doc/2.4.1/lib/module-tempfile.html">Python
tempfile docs</a> for more
information on the default temp directory. The amount of free space
required can vary, but it usually about the size of the largest file
being restored.</p>
<p>Usually free space errors are intelligible, like <code>IOError:
[Errno 28] No space left on device</code> or similar. However, due to
a gzip quirk they may look like <code>ValueError: Incorrect length of data produced</code>.</p>
</li>
<li><strong><a name="librsync_bug">What does "internal error: job made
no progress" mean?</a></strong>
<p>This error happens due to a bug in <code>librsync</code> that prevents
it from handling files greater than 4 GB in some situations, such as
when transferring between a 32-bit host and a 64-bit host.
<a href="https://sourceforge.net/tracker/index.php?func=detail&aid=1439412&group_id=56125&atid=479441">A patch is available</a>
from the librsync project page on Sourceforge. The
<a href="https://sourceforge.net/cvs/?group_id=56125">CVS version</a> of librsync
also contains the patch. More information is also available in
<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355178">Debian bug report #355178</a>.</p>
</li>
<li><strong><a name="path">Why does rdiff-backup say it's not in my $PATH? It is when I login!</a></strong>
<p>If you get an error like <code>sh: line1: rdiff-backup: command not found</code>, but rdiff-backup
<i>is</i> in your <code>$PATH</code> when you login to the remote host, it is happening because the
value of bash's <code>$PATH</code> is set differently when you login to an interactive shell than when you run a command remotely via SSH. For more
information, read the <a href="http://linux.die.net/man/1/bash">bash manpage</a> and look at your
<code>.bashrc</code> and <code>.bash_profile</code> files.</p>
<p>In particular, this can happen if rdiff-backup was installed via Fink on a remote Mac OS X system. <code>/sw/bin</code> is magically added to your <code>$PATH</code> by the script <code>/sw/bin/init.sh</code> when you login with an interative shell. Fink did this behind the scenes when you set it up. Simply add <code>/sw/bin</code> to your path manually, or copy rdiff-backup to a directory that is in your <code>$PATH</code>.</p>
</li>
<li><strong><a name="touple">What does "<code>touple index out of range</code>" mean?</a></strong>
<p>If you see the error "<code>tuple index out of range</code>" after running a command like:<br><br>
<code>$ rdiff-backup -l /path/to/backup/rdiff-backup-data/</code><br><br>
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:<br><br>
<code>$ rdiff-backup -l /path/to/backup</code><br><br>
If you get this error message for an unrelated reason, try contacting the mailing list.</p>
</li>
<li><strong><a name="crc">What does "<code>IO Error: CRC check failed</code>" mean?</a></strong>
<p>This error message means that a
<a href="http://en.wikipedia.org/wiki/Cyclic_redundancy_check">Cyclic Redudancy
Check</a> 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:<br><br>
<code>$ find rdiff-backup-data -type f -name \*.gz -print0 | xargs -0r gzip --test</code><br><br>
will find the failing file. For more information on this approach, see this
mailing list post: <a href="http://lists.nongnu.org/archive/html/rdiff-backup-users/2007-11/msg00008.html">http://lists.nongnu.org/archive/html/rdiff-backup-users/2007-11/msg00008.html</a>.</p>
</li>
<li><strong><a name="badindex">What does "<code>AssertionError: Bad index order</code>" mean?</a></strong>
<p>If rdiff-backup fails with the message "<code>AssertionError: Bad index order</code>," 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.
</p>
<p>If you get this message for an unreleated reason, try contacting the mailing
list.</p>
</li>
<li><strong><a name="utc">How can rdiff-backup use UTC as the timezone?</a></strong>
<p>Like other Unix and Python programs, rdiff-backup respects the <code>TZ</code> environment variable, which can
be used to temporarily change the timezone. On Unix, simply set <code>TZ=UTC</code> either in your shell, or on the
command line used to run rdiff-backup. On Windows, the command <code>USE TZ=UTC</code> sets the <code>%TZ%</code>
environment variable, and can be used either in a batch script, or at the DOS prompt.</p>
</li>
</ol>
</body></html>