Is there any way to back up and restore a filesystem that doesn't upset
If I try the following set of operations:
- Check out a big SVN repository, and build the code
- Back up the SVN checkout folder
- 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
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 (
rsync, and ext4
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?