Is there any way to back up and restore a filesystem that doesn't upset svnversion.

If I try the following set of operations:

  1. Check out a big SVN repository, and build the code
  2. Back up the SVN checkout folder
  3. Restore the SVN checkout to another location

Then the time to run svnversion on the backed up and restored copy is hugely more than on the original:

$ cd original_directory
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
$ time svnversion
real    0m5.204s
user    0m0.486s
sys     0m0.698s
$ cd backed_up_and_restored_directory
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
$ time svnversion
real    1m55.846s
user    0m2.813s
sys     0m5.653s

The echo 3 | sudo tee /proc/sys/vm/drop_caches is to clear the Linux cache so I am measuring "from cold". A second svnversion in either folder takes a fraction of a second.

I am seeing the same sort of result for all the backup technologies I have tried so far (tar, rsync, and ext4 dump/restore). I am also seeing similar behaviour across a variety of file systems (ext4, btrfs, gluster), and Linux distributions (Debian 8, Debian 9 and Ubuntu 16.04)

In answer to Gerard's question, a couple of example backup/restore commands:


rsync -x -aH --whole-file --delete source_directory/ destination_directory


dump 0uaf backup_file.dump .
restore -rf backup_file.dump

I assume this is happening because the restored files and subdirectories are being stored on the disk in a different order, which is making svnversion run very inefficiently on the copy.

Has anyone else experienced this, and does anyone know of a Linux backup/restore technique that will keep the files and directories "in the same order" to prevent this issue?

  • Care to show us the commands your using to backup and restore? I'm not worried about order, but access and modification times of files and folders. Jun 21, 2018 at 13:30
  • I've added some example backup and restore commands to the question details Jun 21, 2018 at 13:56

1 Answer 1


Be sure to retain modification times, eg. with rsync

rsync -t -x -aH --whole-file --delete source_directory/ destination_directory
  • Definitely not that. First, "-a" already implies "-t". Second, I've tried three different backup/restore commands with the same result. Jul 3, 2018 at 10:21
  • Is your "destination" on disks that are very much slower? Jul 5, 2018 at 6:28
  • No. As I've already said several times, I'm 100% sure it is not the timestamps that are the issue. I can see (from 'ls -i') that the file orders are different, which I am pretty sure is what is causing this problem. Jul 6, 2018 at 14:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.