0

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:

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

dump/restore:

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?

Improve this question
2
  • 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. – Gerard H. Pille Jun 21 '18 at 13:30
  • I've added some example backup and restore commands to the question details – Michael Firth Jun 21 '18 at 13:56
0

Be sure to retain modification times, eg. with rsync

rsync -t -x -aH --whole-file --delete source_directory/ destination_directory
Improve this answer
3
  • Definitely not that. First, "-a" already implies "-t". Second, I've tried three different backup/restore commands with the same result. – Michael Firth Jul 3 '18 at 10:21
  • Is your "destination" on disks that are very much slower? – Gerard H. Pille Jul 5 '18 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. – Michael Firth Jul 6 '18 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.