Unofficial cheatcodes to backup and restore persistent data

[utu]

Professor Forester

I must admit I've not done MY homework as promised. Tax time arriveth, you know.
I am taking up our quest again now, however.

To recoup, here's what I think is the current state of affairs:
you have invented patches to give Knoppix 6.4.4 two new cheatcodes, backup
and restore. These two capabilities, in effect, automate the utilzation of the
capability already in 6.4.4 which manages a file update*.tar.gz in a manner to
allow the backing-up and restoration-of the knoppix-data.img file.
These newer offerings utilize squashfs to speed things up beyond the capabilities
of the initial offerings. Only the backup speed improved significantly, but this
may be due to limitations in writing to the USB. Please confirm or correct me here.

In an earlier exchange, you indicated these capabilites could not be realized as
menu items, but only as cheatcodes. I'd like to re-visit this in consideration
of how I might like to apply all this magic. I really would like backup to be a
menu choice to be used during normal on-line use of 6.4.4. Restore I would use
as a cheatcode in addition to my normal DEFAULT set of cheatcodes.

The meaning of backup here is to create a tar.gz of a snapshot of KNOPPIX-DATA,
using squashfs, since it offers an advantage; but do this as a menu choice,
or as a console command, but not as a cheatcode, per se. This I realize is a
complication of your approach to backup. And, I know you are hesitant on doing
the back-up on-line, but I'm not sure it's a show-stopper.

The meaning of restore might be simply to find such a snapshot and restore it
simply per the normal update* process of 6.4.4, since squash seems not to offer
any improvement; do this as a cheatcode to be appended to a normal default.
This might actually be a simplification of your approach to restore.

I need to review for myself if there is any complication in appending a cheatcode
to my normal DEFAULT set of cheatcodes; I don't recall.

I have in the back of my mind how nice Win7 allows system image snapshots, and how
handy these are when something goes funny.

The faster restore is a holy grail for another day. I don't know why the
KNOPPIX file can be unpacked so fast, but not the knoppix-data.img; doesn't make
sense, or it's just not fair, somehow.

[Forester]

utu san,

I wish I could say the confusion is all mine and apologise profusely.

To recoup, here's what I think is the current state of affairs:
you have invented patches to give Knoppix 6.4.4 two new cheatcodes, backup
and restore.

Yes. I'd rather say developed or even elaborated than invented.

These two capabilities, in effect, automate the utilzation of the
capability already in 6.4.4 which manages a file update*.tar.gz in a manner to
allow the backing-up and restoration-of the knoppix-data.img file.

No. I don't use the update*.tar.gz facility. It is not appropriate.

These newer offerings utilize squashfs to speed things up beyond the capabilities
of the initial offerings.

No. This has nothing to do with squashfs.

The first offering used the BusyBox with tar+zlib. The new offering contrives to the full tar + gzip programs available to use from the Knoppix desktop. This cleverness uses facilities KK already uses himself in /init. to run programs not available in BusyBox or minirt, most notably to handle the creation of encrypted knoppix-data.aes files.

Only the backup speed improved significantly, but this
may be due to limitations in writing to the USB. Please confirm or correct me here.

Yes. That is what I wrote.

I really would like backup to be a menu choice to be used during normal on-line use of 6.4.4.

My first question on this forum was how do I add an item to the LXDE menu. As I recall your answer was "I'd like to know too".

You can tar + gzip /KNOPPIX-DATA any time you like. Even a dodgy backup is better than none.

For me, the trouble with a menu item is I'd forget to use it and after a week I'd forget it was there. The same is true for a cheat code but less so, if you know what I mean.

Restore I would use as a cheatcode in addition to my normal DEFAULT set of cheatcodes.

Yes. There is little choice here. You can, naturally, extract individual files from the backup if that's what you need to do.

The meaning of backup here is to create a tar.gz of a snapshot of KNOPPIX-DATA,
using squashfs, since it offers an advantage; but do this as a menu choice,
or as a console command, but not as a cheatcode, per se.

You repeat yourself. No. This has nothing to do with squashfs.

It has to do with 'snapshot' . Think of a snapshot as a digital photograph of your persistent data. You want a clean crisp photo taken while the subject is not moving to avoid blurring of the details. Using a cheat code is the only way of ensuring the photo is taken before the subject starts moving. Backup from menu item means the subject is moving and you won't find out if some crucial detail is blurred until you, out of necessity, have to restore.

This I realize is a complication of your approach to backup. And, I know you are hesitant on doing the back-up on-line, but I'm not sure it's a show-stopper.

No. Taking a shapshot from the command line is so simple I do it everyday but I boot Debian to ensure I take a clean snapshot of Knoppix. Developing the user space shell script I use from Debian was a darn sight easier than adding cheat codes to /init.

The meaning of restore might be simply to find such a snapshot and restore it
simply per the normal update* process of 6.4.4, since squash seems not to offer
any improvement; do this as a cheatcode to be appended to a normal default.
This might actually be a simplification of your approach to restore.

No. There is nothing normal about this or the update* process. Using the update* process involves more error prone manual intervention than a simple cheat code but that is not the reasons using update* is a bad idea. The reason it to do with ensuring deleted files stay deleted.

If someone were to use these cheat codes on a regular basis, I'd suggest they add new boot targets to syslinux.cfg. Instead of typing in knoppix backup_data=/dev/sda6 at the boot: prompt and getting it wrong half the time, they'd type in knoppix_with_backup or something shorter they can easily remember.

I need to review for myself if there is any complication in appending a cheatcode
to my normal DEFAULT set of cheatcodes; I don't recall.

See previous remark.

I have in the back of my mind how nice Win7 allows system image snapshots, and how
handy these are when something goes funny.

That's a system function more akin to saving and restoring from the file system journal. What I have done is a simple user space add-on.

File system journal recovery is for hard drives where the risk of file system corruption through user error is greater than the risk of damage or loss of the hardware medium.

What I have done is intended as much as a protection against the loss or temporary misplacement of my USB stick as it is against the risk that I remove the USB stick from its slot without first shutting down Knoppix.

The faster restore is a holy grail for another day. I don't know why the
KNOPPIX file can be unpacked so fast, but not the knoppix-data.img; doesn't make
sense, or it's just not fair, somehow.

Umm. Nonsense. Unpacking or decompression is always faster than packing or compression. Reading from a USB stick is always faster than writing.

The KNOPPIX file is read and unpacked but only the bits needed, not the whole thing. By definition, backup / restore have to read / write all the bits of persistent store.

Here are my (unrepresentative times):

~ 60 s copy of 1 Gb knoppix-data.img file from USB to hard drive under Debian 6.
~ 30 s tar + gzip of knoppix-data.img file from USB to hard drive under Debian 6.

~ 30 s backup with revised cheat code from USB to hard drive
~ 90 s backup with original cheat code from USB to hard drive

My knoppix-data.img file is currently two thirds full and its backup is almost a ¼ Gb.

The Debian tar + gzip is faster than the cheat code but not when you take into account the time needed to boot and shutdown Debian.

The backup takes several minutes at work because I've a virtual machine with a virtual USB 1.1 controller that is very much slower than a real USB 2.0 controller. The go faster stripe has no effect where I need it most.

Enjoy the simplicity of your tax return form.