iB::Topic::Improving DSL fallover recover

	Damn Small Linux :: Damn Small Linux Board The DSL Forums

» Welcome Guest
[ Log In :: Register ]

Damn Small Linux Board » Damn Small Linux » DSL Ideas and Suggestions » Improving DSL fallover recover

		Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
		Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic

Pages: (2) </ [1] 2 >/

[ Track this topic :: Email this topic :: Print this topic ]

Topic: Improving DSL fallover recover, My suggestion

< Next Oldest | Next Newest >

b1ackmai1er Offline

Group: Members
Posts: 115
Joined: June 2005

Posted: July 07 2006,11:43

Hello again,

I had a problem with DSL booting recently which I tracked down to my restore drive running out of space, so the backup file was incompletely written and the thus corrupt and upon booting (frugal) it hung trying to restore it. The only way I could recover was to boot from a livecd and delete the backup file.

I wanted to suggest making the system more robust by putting in some checks to make sure the system is not left in a damaged state at shutdown or can hang on bootup.

Some suggestions ...

A check that writing the backup file was successfully before shutdown.
Allow the boot process to test the validity of the backup file before restoring.
Installing the skeleton backup file if the corruption is detected.

Regards b1m1

WDef

Group: Members
Posts: 798
Joined: Sep. 2005

Posted: July 08 2006,09:44

Checking that sufficient space is available before writing the backup file in theory is a good idea. The same thing has happened to me before - you lose both your current and former backups

There would be the question, though, of what would be "sufficient" space. AFAIK tar can't estimate the size of an archive before creating it, though it can count total bytes written using --totals

Perhaps a "backup" could be made first to /dev/null, bytes written counted with --totals - this would give the size of the potential backup -pre-compression.

gzip compression ratios spread between about 0.1 and 0.75 so a worst-case multiplier could be used to estimate the max possible size of the backup tarball. If this was greater than df -h showed free on the backup partition, the backup could be aborted.

Haven't tried this, might not work (--totals might not work when writing to /dev/null ?)

WDef

Group: Members
Posts: 798
Joined: Sep. 2005

Posted: July 08 2006,11:10

Tried it, appears it would work.

Writing the uncompressed archive to /dev/null is very fast so this would not slow down the backup process by much, either.

Might try to code it into the backup scripts in the next few days and see how it goes

roberts

Group: Members
Posts: 4983
Joined: Oct. 2003

Posted: July 08 2006,15:20

Just curious, what's in your backup that is taking so much space.
Hopefully not extensions as they should not be. I would guess the fat mail client?
I will take a look into this for v3.1

WDef

Group: Members
Posts: 798
Joined: Sep. 2005

Posted: July 09 2006,09:41

Quote

gzip compression ratios spread between about 0.1 and 0.75 so a worst-case multiplier could be used

I should have said a 'typical' range. Brain was not engaged because, for example, if the user wants to back up a whole lot of compressed files (eg jpegs), obviously gzip will compress these by little or nothing.

So the only max upper bound on size that will always be 100% safe is very close to the size of the uncompressed archive.

Robert, if you're busy and want to wait until I have a go at this for your perusal/modification/rejection/pooh-hooing by all means do so? I'm on holidays so beach takes precedence, but it might make me feel like my current existence has meaning ...

7 replies since July 07 2006,11:43

< Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

Pages: (2) </ [1] 2 >/

Damn Small Linux Board » Damn Small Linux » DSL Ideas and Suggestions » Improving DSL fallover recover