DSL Ideas and Suggestions :: Ultra-fast backup/restores



briljant, thnx
wdef,

I apologize.  I wasn't trying to hijack the topic but it appears that I did.  I don't know how lzop does it, but it looks like it is a real improvement over gzip for the "backup" part of the "backup/restore" process.


However, if the DSL developers are unwilling to go with lzop over gzip in the base ISO, it might still be a good idea to change the "gzip" command in the official DSL backup scripts over to a "gzip -2" command.  This would be a good idea for a  future release of DSL.  It would result in a 7 / 18 = 39% improvement in backup speed while still maintaining gzip compatibility.

But I digress again.

or even better (as far as i see it), maybe have the backup compression be chosen by the user, like the downloads directory is now chosen by the user.  Personally i don't have any issues with the speed of gzip -9, and prefer it to something faster when the size is smaller.  At the same time, there are also people who prefer to go farther to use something like bzip2, which is even smaller, but slower.  If anything is going to change, I don't see any reason why it couldn't be changed in a way that benefits both those who favor speed and those who favor size.
OK, how about this compromise:

a "gzip -$level"

where level is a variable that is extracted from the .dslrc settings file?

Of course, my strong preference is to have "2" be the default value in the file, because it is ~40% faster but with only a ~5% size penalty.

Quote
..a "gzip -$level"

where level is a variable that is extracted from the .dslrc settings file?


Up to the developers, it wouldn't be difficult. Some configurability is better than none?

I'll put it in the hacked script if you like.

Quote
... I wasn't trying to hijack the topic..

No problem - stuff needs to be said.  I'm just keen to get feedback/bugs on the filetool.sh mods.

Quote
if the DSL developers are unwilling to go with lzop over gzip in the base


Your opinion would count. For me, it's not an issue  - I'll just continue to load my extensions. These could go into the repository  - I've emailed Ke4NT re lzop.dsl.  If Robert agrees (he is the original filetool.sh author), fastbackup.dsl perhaps could go there later.

Quote
...even better (as far as i see it), maybe have the backup compression be chosen by the user


Had similar thinking:

Quote
very easy to change the hack to be able to use lzma, bzip2 or any other comp programs  .. You could then take your pick ..


I spoke a bit soon with the "very" in "very easy" because of the different command switches/syntax with some of these progs (p7zip etc).  But a restricted generalisation is doable - I think I'll try it.

Interesting what Patrick said about CPU load:
Quote
Processor used to hit the roof when backing up (100%) now that's in the past.


Anyone else noticed this?

Next Page...
original here.