Description of problem: fwbackups compresses the end resulting backup file rather than letting tar compress on the fly. > # gzip at end if needed > if self.engine == 'tar.gz': There are a couple of reasons why this is not ideal: 1) Saving to a network drive uses up to 3x the bandwith of the backups set (write, read, write-compressed) 2) Saving to a network drive uses up to 2x the original file size to store during the backup process (original size + compressed size, until finished) 3) Saving to a network drive increases the total backup time because of the extra r/w. Version-Release number of selected component (if applicable): fwbackups-1.43.0-0.1.beta2.fc6
Example of wasted time. Approximately 80 minutes to write archive, then an additional 115 minutes to compress it after the fact. INFO :: Apr 26 06:00:02: Starting automatic backup of set 'bjohnson' INFO :: Apr 26 07:20:07: Compressing the backup archive... INFO :: Apr 26 09:15:11: Finished automatic backup of set 'bjohnson'
The way I designed the restore/backup functions I would need to rewrite quite a bit to get this done and at the moment I don't have very much time, however this will be my top priority for 1.43.1 which will be soon after 1.43.0 is released.
Just a little update - this issue was bugging me, so I fixed this in RC1. I update it in the repos once Fedora 7 comes out of the freeze.
Excellent. I just got back from a trip so I installed rc2 today to give it a spin.
Hmm. When I upgraded, it looks like the crontab file got botched: $ crontab -l 0 6 * * * fwbackups-run My backup didn't run this morning because there was no backup set specified. I removed that crontab entry and saved the backup set again and it saved the crontab correctly: $ crontab -l 0 6 * * * fwbackups-run 'bjohnson'
That's funny, I had noticed that too but after the first indecent I couldn't manage to reproduce it...
*indecent -> incident... I'm going to close this ticket as it's resolved in the latest build.