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
Version-Release number of selected component (if applicable):
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 -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.