1--- 2pagetitle: rdiff-backup FAQ 3--- 4rdiff-backup FAQ 5================ 6 7### [Table of contents]{#ToC3} 8 91. [What do the different verbosity levels mean?](#verbosity) 102. [Is rdiff-backup backwards compatible?](#compatible) 113. [Does rdiff-backup run under Windows?](#windows) 124. [Does rdiff-backup run under Mac OS X?](#OSX) 135. [Can I backup files to a CIFS or smbfs mount?](#cifs) 146. [Help! Why do all my filenames now look like ;077y;070ile 15 ?!](#case_insensitive) 167. [My backup set contains some files that I just realized I don\'t 17 want/need backed up. How do I remove them from the backup volume to 18 save space?](#remove_dir) 198. [Does rdiff-backup work under Solaris?](#solaris) 209. [How fast is rdiff-backup? Can it be run on large data 21 sets?](#speed) 2210. [What do the various fields mean in the session statistics and 23 directory statistics files?](#statistics) 2411. [Is there some way to limit rdiff-backup\'s bandwidth usage, as in 25 rsync\'s \--bwlimit option?](#bwlimit) 2612. [How much memory should rdiff-backup use? Is there a memory 27 leak?](#leak) 2813. [I use NFS and keep getting some error that includes \"OSError: 29 \[Errno 39\] Directory not empty\"](#dir_not_empty) 3014. [For some reason rdiff-backup failed while backing up. Now every 31 time it runs it says \"regressing destination\" and then fails 32 again. What should I do?](#regress_failure) 3315. [Where does rdiff-backup need free space and how much is required? 34 What is the problem if rdiff-backup says 35 \"`ValueError: Incorrect length of data produced`\"?](#free_space) 3616. [What does \"internal error: job made no progress\" 37 mean?](#librsync_bug) 3817. [Why does rdiff-backup say it\'s not in my \$PATH? It is when I 39 login!](#path) 4018. [What does \"`touple index out of range`\" mean?](#touple) 4119. [What does \"`IO Error: CRC check failed`\" mean?](#crc) 4220. [What does \"`AssertionError: Bad index order`\" mean?](#badindex) 4321. [How can rdiff-backup use UTC as the timezone?](#utc) 44 45### [Questions and Answers]{#ToC4} 46 471. **[What do the different verbosity levels mean?]{#verbosity}** 48 49 There is no formal specification, but here is a rough description 50 (settings are always cumulative, so 5 displays everything 4 does): 51 52 --- ---------------------------------------------------------------------- 53 0 No information given 54 1 Fatal Errors displayed 55 2 Warnings 56 3 Important messages, and maybe later some global statistics (default) 57 4 Some global settings, miscellaneous messages 58 5 Mentions which files were changed 59 6 More information on each file processed 60 7 More information on various things 61 8 All logging is dated 62 9 Details on which objects are moving across the connection 63 --- ---------------------------------------------------------------------- 64 652. **[Is rdiff-backup backwards compatible?]{#compatible}** 66 67 In general, rdiff-backup does not strive to make newer clients 68 compatible with older servers (or vice versa). However, there is no 69 intention to purposefully make different versions incompatible 70 across the network \-- changes are introduced primarily to fix bugs 71 or introduce new features that cannot be implemented without 72 breaking the network protocol. Furthermore, rdiff-backup does try to 73 make it possible to read older archives. 74 75 When running as a client, rdiff-backup checks the version of 76 rdiff-backup running on the server, and prints a warning message if 77 the two versions are different. If you have any problems with your 78 backup, it is strongly recommended that you upgrade the older 79 version before reporting any issues. 80 813. **[Does rdiff-backup run under Windows?]{#windows}** 82 83 Yes, although it is not a heavily tested configuration. Rdiff-backup 84 can be run as a native Windows application or under Cygwin. To run 85 as a native Windows application, simply download the provided .exe 86 binary. To setup remote operation, you will also need an SSH client, 87 such as [Putty](https://www.chiark.greenend.org.uk/~sgtatham/putty/) 88 or [SSH Secure Shell](https://www.ssh.com). 89 90 If you wish to run rdiff-backup under Cygwin, use at least version 91 1.1.12. The setup under Cygwin is the same as under other Unix-like 92 operating systems. From the Cygwin installer you will need Python 93 3.5 or higher (under Interpreters), autoconf, automake, binutils, 94 gcc, make, and patchutils (all under Devel). Then you will need to 95 compile and install librsync, which can be downloaded [from 96 Sourceforge](https://sourceforge.net/project/showfiles.php?group_id=56125). 97 Finally, you can compile and install rdiff-backup using the usual 98 instructions. 99 100 Although some Windows filesystems lack features like FIFOs, case 101 sensitive filenames, or files with colons (\":\") in them, all of 102 these situations should be autodetected and compensated for by 103 rdiff-backup. 104 105 If you would like more detailed instructions for compiling and 106 installing rdiff-backup on Cygwin, you can read this blog entry: 107 <https://katastrophos.net/andre/blog/2005/11/02/rdiff-backup-on-windows/>. 108 Note: The patch that the blog suggests that you download is no 109 longer necessary starting with version 1.1.8 of rdiff-backup. 110 1114. **[Does rdiff-backup run under Mac OS X?]{#OSX}** 112 113 Yes, quite a few people seem to be using rdiff-backup under Mac 114 OS X. rdiff-backup can also backup resource forks and other Mac OS X 115 metadata to a traditional unix filesystem, which is can be a handy 116 feature for Mac users. When rdiff-backup is used to do the restore, 117 all of the metadata is recovered from rdiff-backup\'s storage. 118 119 The easiest option is probably to use Fink 120 <http://fink.sourceforge.net/>, which can install rdiff-backup 121 automatically for you. With Fink, you should install the `librsync`, 122 `librsync-shlibs`, `python25`, `python25-shlibs`, `xattr-py25`, and 123 `rdiff-backup` packages. Another option is DarwinPorts 124 <https://www.macports.org/>, for which you should install the 125 `py-xattr` and `rdiff-backup` packages. 126 127 If you want to build rdiff-backup yourself, you should be able to 128 build librsync and rdiff-backup using the standard Unix 129 instructions. You can also see this message from Gerd Knops: 130 131 From: Gerd Knops <gerti@bitart.com> 132 Date: Thu, 3 Oct 2002 03:56:47 -0500 (01:56 PDT) 133 134 [parts of original message deleted] 135 these instructions build it fine with all tests running OK 136 (librsync-0.9.5.1 on OS X 10.2.1): 137 138 aclocal 139 autoconf 140 automake --foreign --add-missing 141 env CFLAGS=-no-cpp-precomp ./configure 142 make 143 make install 144 145 An important note if you use the Apple-provided version of Python: 146 Apple\'s version of Python will install rdiff-backup in something 147 like 148 `/System/Library/Frameworks/Python.framework/Versions/Current/bin/rdiff-backup` 149 and `rdiff-backup` will not be in your `$PATH`. You can copy 150 rdiff-backup out of this folder and into someplace reasonable like 151 `/usr/bin` or another directory in your `$PATH` to use it. For a 152 full explanation of why this happens see this post to the mailing 153 list: 154 <https://lists.nongnu.org/archive/html/rdiff-backup-users/2007-06/msg00107.html>. 155 1565. **[Can I backup files to a CIFS or smbfs mount?]{#cifs}** 157 158 You can certainly try! Using a CIFS or smbfs mount as the mirror 159 directory has been troublesome for some users because of the wide 160 variety of Samba configurations. If possible, the best solution is 161 always to use rdiff-backup over SSH in the default configuration. 162 Using rdiff-backup in the default configuration is also guaranteed 163 to be faster because there is lower network utilization. 164 Rdiff-backup uses the rsync algorithm to minimize the amount of 165 bandwidth consumed. By using smbfs or CIFS, the complete file is 166 transferred over the network. 167 168 Under both Linux and Mac OS X, smbfs seems to be working quite well. 169 However, it has a 2 GB file limit and is deprecated on Linux. CIFS 170 users sometimes experience one of these common errors: 171 172 - rdiff-backup fails to run, printing an exception about 173 \"`assert not upper_a.lstat()`\" failing. This can be resolved 174 by unmounting the share, running the following command as root:\ 175 `$ echo 0 > /proc/fs/cifs/LookupCacheEnabled`\ 176 and then remounting the CIFS share.\ 177 \ 178 - If filenames in the mirror directory have some characters 179 transformed to a \'?\' instead of remaining the expected Unicode 180 character, you will need to adjust the `iocharset=` mount 181 option. This happens because the server is using a codepage with 182 only partial Unicode support and is not translating characters 183 correctly. See the mount.cifs man page for more information. 184 Using smbfs can also improve this situation since it has both an 185 `iocharset=` and a `codepage=` option. 186 - If you have trouble with filenames containing a colon \':\', or 187 another reserved Windows character, try using the `mapchars` 188 option to the CIFS mount. At least one user has reported success 189 when using this option while mounting a NAS system via CIFS. See 190 the mount.cifs man page for more information.\ 191 \ 192 - Other CIFS mount options which may be helpful include `nocase`, 193 `directio`, and `sfu`. Also, try changing the value of 194 `/proc/fs/cifs/LinuxExtensionsEnabled` (requires remount). A 195 user with a DroboShare reported that 196 `-o mapchars,nocase,directio` worked for that NAS appliance. 197 198 If you\'re still having trouble backing up to a CIFS or smbfs mount, 199 try searching the [mailing-list 200 archives](https://lists.gnu.org/archive/html/rdiff-backup-users/) 201 and then sending further questions to the list. 202 2036. **[Help! Why do all my filenames now look like ;077y;070ile 204 ?!]{#case_insensitive}** 205 206 When backing up from a case-sensitive filesystem to a 207 case-insensitive filesystem (such as Mac\'s HFS+ or Windows\'s FAT32 208 or NTFS), rdiff-backup escapes uppercase characters in filenames to 209 make sure that no files are accidentally overwritten. When a 210 filesystem is case-preserving but case-insensitive, it means that it 211 remembers that a file is named \"Foo\" but doesn\'t distinguish 212 between \"Foo\", \"foo\", \"foO\", \"fOo\", etc. However, 213 filesystems such as Linux\'s ext3 do treat these names as separate 214 files. 215 216 Imagine you have a Linux directory with two files, \"bar\" and 217 \"BAR\", and you copy them to a Mac system. You will wind up with 218 only one file (!) since HFS+ doesn\'t distinguish between the names, 219 and the second file copied will overwrite the first. Therefore, when 220 rdiff-backup copies files from case-sensitive to case-insensitive 221 filesystems, it escapes the uppercase characters (eg, \"M\" is 222 replaced with \";077\", and \"F\" with \";070\") so that no filename 223 conflicts occur. Upon restore (from the Mac backup server to the 224 Linux system), the filenames are unquoted and you will get 225 \"MyFile\" back. 226 2277. **[My backup set contains some files that I just realized I don\'t 228 want/need backed up. How do I remove them from the backup volume to 229 save space?]{#remove_dir}** 230 231 The only official way to remove files from an rdiff-backup 232 repository is by letting them expire using the \--remove-older-than 233 option. Deleting increments from the rdiff-backup-data directory 234 will prevent you from recovering those files, but shouldn\'t prevent 235 the rest of the repository from being restored. 236 2378. **[Does rdiff-backup work under Solaris?]{#solaris}** 238 239 There may be a problem with rdiff-backup and Solaris\' libthread. 240 Adding \"ulimit -n unlimited\" may fix the problem though. Here is a 241 post by Kevin Spicer on the subject: 242 243 Subject: RE: Crash report....still not^H^H^H working 244 From: "Spicer, Kevin" <kevin.spicer@bmrb.co.uk> 245 Date: Sat, 11 May 2002 23:36:42 +0100 246 To: rdiff-backup@keywest.Stanford.EDU 247 248 Quick mail to follow up on this.. 249 My rdiff backup (on Solaris 2.6 if you remember) has now worked 250 reliably for nearly two weeks after I added... 251 252 ulimit -n unlimited 253 254 to the start of my cron job and created a wrapper script on the remote 255 machine which looked like this... 256 257 ulimit -n unlimited 258 rdiff-backup --server 259 exit 260 261 And changed the remote schema on the command line of rdiff-backup to 262 call the wrapper script rather than rdiff-backup itself on the remote 263 machine. As for the /dev/zero thing I've done a bit of Googleing and 264 it seems that /dev/zero is used internally by libthread on Solaris 265 (which doesn't really explain why its opening more than 64 files - but 266 at least I think I've now got round it). 267 2689. **[How fast is rdiff-backup? Can it be run on large data 269 sets?]{#speed}** 270 271 rdiff-backup can be limited by the CPU, disk IO, or available 272 bandwidth, and the length of a session can be affected by the amount 273 of data, how much the data changed, and how many files are present. 274 That said, in the typical case the number/size of changed files is 275 relatively small compared to that of unchanged files, and 276 rdiff-backup is often either CPU or bandwidth bound, and takes time 277 proportional to the total number of files. Initial mirrorings will 278 usually be bandwidth or disk bound, and will take much longer than 279 subsequent updates. 280 281 To give one arbitrary data point, when I back up my personal HD 282 locally (about 36GB, 530000 files, maybe 500 MB turnover, Athlon 283 2000, 7200 IDE disks, version 0.12.2) rdiff-backup takes about 15 284 minutes and is usually CPU bound. 285 28610. **[What do the various fields mean in the session statistics and 287 directory statistics files?]{#statistics}** 288 289 Let\'s examine an example session statistics file: 290 291 StartTime 1028200920.44 (Thu Aug 1 04:22:00 2002) 292 EndTime 1028203082.77 (Thu Aug 1 04:58:02 2002) 293 ElapsedTime 2162.33 (36 minutes 2.33 seconds) 294 SourceFiles 494619 295 SourceFileSize 8535991560 (7.95 GB) 296 MirrorFiles 493797 297 MirrorFileSize 8521756994 (7.94 GB) 298 NewFiles 1053 299 NewFileSize 23601632 (22.5 MB) 300 DeletedFiles 231 301 DeletedFileSize 10346238 (9.87 MB) 302 ChangedFiles 572 303 ChangedSourceSize 86207321 (82.2 MB) 304 ChangedMirrorSize 85228149 (81.3 MB) 305 IncrementFiles 1857 306 IncrementFileSize 13799799 (13.2 MB) 307 TotalDestinationSizeChange 28034365 (26.7 MB) 308 Errors 0 309 310 StartTime and EndTime are measured in seconds since the epoch. 311 ElapsedTime is just EndTime - StartTime, the length of the 312 rdiff-backup session. 313 314 SourceFiles are the number of files found in the source directory, 315 and SourceFileSize is the total size of those files. MirrorFiles are 316 the number of files found in the mirror directory (not including the 317 rdiff-backup-data directory) and MirrorFileSize is the total size of 318 those files. All sizes are in bytes. If the source directory hasn\'t 319 changed since the last backup, MirrorFiles == SourceFiles and 320 SourceFileSize == MirrorFileSize. 321 322 NewFiles and NewFileSize are the total number and size of the files 323 found in the source directory but not in the mirror directory. They 324 are new as of the last backup. 325 326 DeletedFiles and DeletedFileSize are the total number and size of 327 the files found in the mirror directory but not the source 328 directory. They have been deleted since the last backup. 329 330 ChangedFiles are the number of files that exist both on the mirror 331 and on the source directories and have changed since the previous 332 backup. ChangedSourceSize is their total size on the source 333 directory, and ChangedMirrorSize is their total size on the mirror 334 directory. 335 336 IncrementFiles is the number of increment files written to the 337 rdiff-backup-data directory, and IncrementFileSize is their total 338 size. Generally one increment file will be written for every new, 339 deleted, and changed file. 340 341 TotalDestinationSizeChange is the number of bytes the destination 342 directory as a whole (mirror portion and rdiff-backup-data 343 directory) has grown during the given rdiff-backup session. This is 344 usually close to IncrementFileSize + NewFileSize - DeletedFileSize + 345 ChangedSourceSize - ChangedMirrorSize, but it also includes the 346 space taken up by the hardlink\_data file to record hard links. 347 34811. **[Is there some way to limit rdiff-backup\'s bandwidth usage, as in 349 rsync\'s \--bwlimit option?]{#bwlimit}** 350 351 There is no internal rdiff-backup option to do this. However, 352 external utilities such as 353 [cstream](https://www.cons.org/cracauer/cstream.html) can be used to 354 monitor bandwidth explicitly. trevor\@tecnopolis.ca writes: 355 356 rdiff-backup --remote-schema 357 'cstream -v 1 -t 10000 | ssh %s '\''rdiff-backup --server'\'' | cstream -t 20000' 358 'netbak@foo.bar.com::/mnt/backup' localbakdir 359 360 (must run from a bsh-type shell, not a csh type) 361 362 That would apply a limit in both directions [10000 bytes/sec outgoing, 363 20000 bytes/sec incoming]. I don't think you'd ever really want to do 364 this though as really you just want to limit it in one direction. 365 Also, note how I only -v 1 in one direction. You probably don't want 366 to output stats for both directions as it will confuse whatever script 367 you have parsing the output. I guess it wouldn't hurt for manual runs 368 however. 369 370 To only limit bandwidth in one directory, simply remove one of the 371 cstream commands. Two cstream caveats may be worth mentioning: 372 373 1. Because cstream is limiting the uncompressed data heading into 374 or out of ssh, if ssh compression is turned on, cstream may be 375 overly restrictive. 376 2. cstream may be \"bursty\", limiting average bandwidth but 377 allowing rdiff-backup to exceed it for significant periods. 378 379 Another option is to limit bandwidth at a lower (and perhaps more 380 appropriate) level. Adam Lazur mentions [The Wonder 381 Shaper](https://lartc.org/wondershaper/). 382 38312. **[How much memory should rdiff-backup use? Is there a memory 384 leak?]{#leak}** 385 386 The amount of memory rdiff-backup uses should not depend much on the 387 size of directories being processed. Keeping track of hard links may 388 use up memory, so if you have, say, hundreds of thousands of files 389 hard linked together, rdiff-backup may need tens of MB. 390 391 If rdiff-backup seems to be leaking memory, it is probably because 392 it is using an early version of librsync. **librsync 0.9.5 leaks 393 lots of memory.** Later versions should not leak and are available 394 from the [librsync 395 homepage](https://sourceforge.net/projects/librsync/). 396 39713. **[I use NFS and keep getting some error that includes \"OSError: 398 \[Errno 39\] Directory not empty\"]{#dir_not_empty}** 399 400 Several users have reported seeing errors that contain lines like 401 this: 402 403 File "/usr/lib/python2.2/site-packages/rdiff_backup/rpath.py", 404 line 661, in rmdir 405 OSError: [Errno 39] Directory not empty: 406 '/nfs/backup/redfish/win/Program Files/Common Files/GMT/Banners/11132' 407 Exception exceptions.TypeError: "'NoneType' object is not callable" 408 in <bound method GzipFile.__del__ of 409 410 All of these users were backing up onto NFS (Network File System). I 411 think this is probably a bug in NFS, although tell me if you know 412 how to make rdiff-backup more NFS-friendly. To avoid this problem, 413 run rdiff-backup locally on both ends instead of over NFS. This 414 should be faster anyway. 415 41614. **[For some reason rdiff-backup failed while backing up. Now every 417 time it runs it says \"regressing destination\" and then fails 418 again. What should I do?]{#regress_failure}** 419 420 Firstly, this shouldn\'t happen. If it does, it indicates a 421 corrupted destination directory, a bug in rdiff-backup, or some 422 other serious recurring problem. 423 424 However, here is a workaround that you might want to use, even 425 though it probably won\'t solve the underlying problem: In the 426 destination\'s rdiff-backup-data directory, there should be two 427 \"current\_mirror\" files, for instance: 428 429 current_mirror.2003-09-07T16:43:00-07:00.data 430 current_mirror.2003-09-08T04:22:01-07:00.data 431 432 Delete the one with the earlier date. Also move the mirror\_metadata 433 file with the later date out of the way, because it probably didn\'t 434 get written correctly because that session was aborted: 435 436 mv mirror_metadata.2003-09-08T04:22:01-07:00.snapshot.gz aborted-metadata.2003-09-08T04:22:01-07:00.snapshot.gz 437 438 The next time rdiff-backup runs it won\'t try regressing the 439 destination. Metadata will be read from the file system, which may 440 result in some extra files being backed up, but there shouldn\'t be 441 any data loss. 442 44315. **[Where does rdiff-backup need free space and how much is required? 444 What is the problem when rdiff-backup says 445 \"`ValueError: Incorrect length of data produced`\"?]{#free_space}** 446 447 When backing up, rdiff-backup needs free space in the mirror 448 directory. The amount of free space required is usually a bit more 449 than the size of the file getting backed up, but can be as much as 450 twice the size of the current file. For instance, suppose you ran 451 `rdiff-backup foo bar` and the largest file, `foo/largefile`, was 452 1GB. Then rdiff-backup would need 1+GB of free space in the `bar` 453 directory. 454 455 When restoring or regressing, rdiff-backup needs free space in the 456 default temp directory. Under unix systems this is usually the 457 `/tmp` directory. The temp directory that rdiff-backup uses can be 458 set using the `--tempdir` and `--remote-tempdir` options available 459 in versions 1.1.13 and newer. See the entry for `tempfile.tempdir` 460 in the [Python tempfile 461 docs](https://docs.python.org/3/library/tempfile.html) for more 462 information on the default temp directory. The amount of free space 463 required can vary, but it usually about the size of the largest file 464 being restored. 465 466 Usually free space errors are intelligible, like 467 `IOError: [Errno 28] No space left on device` or similar. However, 468 due to a gzip quirk they may look like 469 `ValueError: Incorrect length of data produced`. 470 47116. **[What does \"internal error: job made no progress\" 472 mean?]{#librsync_bug}** 473 474 This error happens due to a bug in `librsync` that prevents it from 475 handling files greater than 4 GB in some situations, such as when 476 transferring between a 32-bit host and a 64-bit host. [A patch is 477 available](https://sourceforge.net/tracker/index.php?func=detail&aid=1439412&group_id=56125&atid=479441) 478 from the librsync project page on Sourceforge. The [CVS 479 version](https://sourceforge.net/cvs/?group_id=56125) of librsync 480 also contains the patch. More information is also available in 481 [Debian bug report 482 \#355178](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355178). 483 48417. **[Why does rdiff-backup say it\'s not in my \$PATH? It is when I 485 login!]{#path}** 486 487 If you get an error like 488 `sh: line1: rdiff-backup: command not found`, but rdiff-backup *is* 489 in your `$PATH` when you login to the remote host, it is happening 490 because the value of bash\'s `$PATH` is set differently when you 491 login to an interactive shell than when you run a command remotely 492 via SSH. For more information, read the [bash 493 manpage](https://linux.die.net/man/1/bash) and look at your 494 `.bashrc` and `.bash_profile` files. 495 496 In particular, this can happen if rdiff-backup was installed via 497 Fink on a remote Mac OS X system. `/sw/bin` is magically added to 498 your `$PATH` by the script `/sw/bin/init.sh` when you login with an 499 interactive shell. Fink did this behind the scenes when you set it 500 up. Simply add `/sw/bin` to your path manually, or copy rdiff-backup 501 to a directory that is in your `$PATH`. 502 50318. **[What does \"`touple index out of range`\" mean?]{#touple}** 504 505 If you see the error \"`tuple index out of range`\" after running a 506 command like:\ 507 \ 508 `$ rdiff-backup -l /path/to/backup/rdiff-backup-data/`\ 509 \ 510 then the solution is to simply remove the extra 511 \"rdiff-backup-data\" from the end of the path. The list increments 512 option, and others like it, take the path to the repository, not the 513 path to the rdiff-backup-data directory. In the above example, you 514 should run again with:\ 515 \ 516 `$ rdiff-backup -l /path/to/backup`\ 517 \ 518 If you get this error message for an unrelated reason, try 519 contacting the mailing list. 520 52119. **[What does \"`IO Error: CRC check failed`\" mean?]{#crc}** 522 523 This error message means that a [Cyclic Redundancy 524 Check](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) failed 525 during some operation, most likely while gzip\'ing or un-gzip\'ing a 526 file. Possible causes of this error include an incomplete gzip 527 operation, and hardware failure. A brute-force way to recover from 528 this error is to remove the rdiff-backup-data directory. However, 529 this will remove all of your past increments. A better approach may 530 be to delete the particular file that is causing the problem. A 531 command like:\ 532 \ 533 `$ find rdiff-backup-data -type f -name \*.gz -print0 | xargs -0r gzip --test`\ 534 \ 535 will find the failing file. For more information on this approach, 536 see this mailing list post: 537 <https://lists.nongnu.org/archive/html/rdiff-backup-users/2007-11/msg00008.html>. 538 53920. **[What does \"`AssertionError: Bad index order`\" 540 mean?]{#badindex}** 541 542 If rdiff-backup fails with the message 543 \"`AssertionError: Bad index order`,\" it could be because the files 544 in a directory have changed while rdiff-backup is running. Possible 545 ways of dealing with this situation include implementing filesystem 546 snapshots using the volume manager, excluding the offending 547 directory, or suspending the process that is changing the directory. 548 After the text \"Bad index order\", the error message will indicate 549 which files have caused the problem. 550 551 If you get this message for an unrelated reason, try contacting the 552 mailing list. 553 55421. **[How can rdiff-backup use UTC as the timezone?]{#utc}** 555 556 Like other Unix and Python programs, rdiff-backup respects the `TZ` 557 environment variable, which can be used to temporarily change the 558 timezone. On Unix, simply set `TZ=UTC` either in your shell, or on 559 the command line used to run rdiff-backup. On Windows, the command 560 `USE TZ=UTC` sets the `%TZ%` environment variable, and can be used 561 either in a batch script, or at the DOS prompt. 562