Archive Restoration Speed

Please ask questions here if you are not familiar with fsarchiver
Post Reply
ozar
Posts: 6
Joined: Fri Jun 25, 2010 12:20 am

Archive Restoration Speed

Post by ozar » Fri Jun 25, 2010 12:34 am

Many thanks to the developer for this wonderful utility, as it has worked well each time that I've used it.

I do, however, have a question about the speed in which it restores an archive. On creating the archived image in question, it takes about 2 minutes and 45 seconds to complete the task, but upon restoring the archive to the same partitions from which it was created, it takes about 6 minutes and 10 seconds to complete. Note that I am using the -j3 option for my 4-core processor on both the creation and restoration of the archived images.

Here are the two commands that I'm using to complete these tasks:

fsarchiver -j3 -o savefs /path/to/name_of_backup.fsa /dev/sda1 /dev/sda6
fsarchiver -j3 restfs /path/to/name_of_backup.fsa id=0,dest=/dev/sda1 id=1,dest=/dev/sda6

Is this much of a time difference in creation and restoration normal, or is there something that I might be doing wrong in the process?

Thanks to anyone that can offer assistance.

Edit: Forgot to say that I'm using version 0.6.10, the latest stable version I believe.

admin
Site Admin
Posts: 550
Joined: Sat Feb 21, 2004 12:12 pm

Re: Archive Restoration Speed

Post by admin » Tue Jun 29, 2010 9:47 am

If you are restoring quite small filesystems to a large partition, creating a filesystem using static inodes (eg: ext3) can take a lot of time, so the overhead may be important. You can see how much time it takes when you sue restfs with the "-v" option. Inodes are created only when needed on other filesystems (xfs, reiserfs) so mkfs it much faster.

In general decompression takes less time than compression. It's true with gzip and lzma has a very fast decompression. But sometimes it may be quicker to use high compression if you have a good cpu. With a better compression level you have less data to read/write on the disk since the archive is smaller. And then it can save some time.

You can also try using "-j" to use multiple compression / decompression threads which makes a big difference on quad core machines. It's quite difficult to say why decompression is slow in that particular case, you should run "dstat 30" to see how much CPU / Disk is being used, and determine which resource is used 100%.

ozar
Posts: 6
Joined: Fri Jun 25, 2010 12:20 am

Re: Archive Restoration Speed

Post by ozar » Tue Jun 29, 2010 5:47 pm

Thanks for the additional information.

It is indeed the ext3 filesystem being compressed and restored, and it is a relatively small filesystem that is being restored to a much larger partition. I'm already using the -j option as indicated in my original post but that hasn't helped with the decompression/restoration speed issue. Sorry, I should have used code tags on the commands above so they'd have been easier to spot.

Since posting originally, I've moved to a fast SSD and the ext4 filesystem, and both the compression and restoration phases are very much quicker now, although the decompression phase still seems to be taking slightly longer than the compression phase. It all seems fine now but I'll report back should the speeds become an issue.

Thanks again for your help.

Post Reply