Self-Contained Backup for Persistent-Store

.
The following is offered as a 'proof of principle' example for
prospective future modification of, or inclusion into Knoppix.
This idea has been employed with satisfactory outcome by me for
some time. This idea builds upon an already available feature
of the current Knoppix distribution.

Back-up & restore for 2 GB Knoppix 6.4.4 LiveUSB Persistent-store

0. When making a LiveUSB from the Knoppix LiveCD, allow 850 Mb for
persistent store; this leaves 350 Mb in /mnt-system for a com-
pressed persistent-store backup, update.tar.gz. Save the LiveCD.
If more than 1200 Mb is available and useful, then just preserve
a 2.5:1 ratio of persistent:compressed storage allotments.

1. Occasionally, while the LiveUSB is in active use, make a
compressed copy of the filesystem /KNOPPIX-DATA, name this
update.tar.gz, and then save* it in the /mnt-sytem/ directory,
or replace an older update.tar.gz there with a newer one.
*Hint: use or invent something like /etc/backup, see below.

2. When needed to restore the previous persistent-store info,
assuming the non-Live USB is at sdb1, use a LiveCD to move* what
now appears as
/media/sdb1/update.tar.gz one level to
/media/sdb1/KNOPPIX/update.tar.gz, then dismiss the LiveCD
and reboot the modified LiveUSB.
*Hint: using the LiveCD's PCManFM to drag & drop is the easy way.

3. After rebooting the modified LiveUSB & before shut-down, move*
/mnt-system/KNOPPIX/update.tar.gz back one level to
/mnt-system/update.tar.gz for safe-keeping until the next time
a restore is needed. Don't leave it in the /KNOPPIX directory.
*Hint: use the LiveUSB's PCManFM to drag & drop this time.

4. Back to step 1.
__________________________________________________ ______________

#!/bin/bash
#
# /etc/backup Note: make this root:root and executable
#
echo 'Saving update.tar.gz to /mnt-system.'
echo -e 'Patience; this may take a little time..\c'
#
cd /
tar -cf /tmp/update.tar KNOPPIX-DATA
cd /tmp
gzip update.tar
mv update.tar.gz /mnt-system
#
echo '..Done.'
#
exit 0

Nice! I'm very bad at bash scripting, but I have some comments/suggestions:
1. mv -f update.tar.gz /mnt-system will replace an existing update version, won't it?
2. I think minirt.gz should be modified to move the update.tar.gz out of /KNOPPIX after updating the persistent store - if it does not already.
3. The critical step, copying a live file system, is tarring. Maybe a note to the user when this is done?
4. This could be implemented with two USB sticks, rather than stick+ live CD. But, also, why couldn't the update file be moved into KNOPPIX by the running system itself?
5. /usr/local/bin is an alternative place for such scripts.

@ Capricorny

Thanks for your comments. In answer to same:
1..Yes, that is the intention.
2. That's a neat idea in itself. Right around line 738 of init of minirt.gz, to be specific
...is the operative area of the code. But, won't that require a re-mastering?
3..Not sure what your concern is here. Tarring /KNOPPIX was my crude idea of how to proceed.
...A more elegant approach would use knoppix-data.img, but I wasn't clear on just what .img
...means. I expect it has to do with loops. Tar is simple and available. Most of the time
...is spent in gzipping, not tarring.
4a.I keep a belt-and-suspenders copy of the update on another usb. What I feel is unique here
...is keeping a self-contained backup. Being able to do this on a 2 Gb set-up surprised me.
...Both the update and the persistent stores on my set-up are only half-full after six months
...of tweaking.
4b.The reason I decided I need a backup, is some of my tweakings result in a LiveUSB that's
...not Live anymore. Of course if it isn't dead, it should serve the purpose as well. If not
...you need a working Linux to make the repair. In my case I just use the old LiveCD.
5..Anybody's choice here; could be in /home, just as well.

__________________________________________________ ___________________________________________

I probably should have prefaced my example with the thought that by 'proof of principle' that
it's the idea that counts, not the specific implementation of the example. Having struggled
to read even parts of Knoppix's minirt.gz, I know there are lots of other ways to do things,
than I had ever run across before.

Correction:
Item 3, second sentence, should read 'Tarring /KNOPPIX-DATA (the filesystem) was ...'

Here's the stanza beginning at line 734 of the init of minirt.gz
...with two added lines defining a new cheatcode "restore":

# Check for updates on-disk, install them if necessary. ############## line 734
if checkbootparam "restore" then ####################### first added line
ls /mnt-system/KNOPPIX/update*.zip /mnt-system/KNOPPIX/update*.tar.gz\
/mnt-system/KNOPPIX/update*.taz 2>/dev/null | while read update; do
if [ -r "$update" ]; then
message -e "\r${CRE}${GREEN}${UPDATING} ${YELLOW}$update${NORMAL}"
case "$update" in
*.zip) ( cd / ; unzip -o "$update" >/dev/null 2>&1 ) ;;
*.tar.gz|*.taz) ( cd / ; tar -zxf "$update" >/dev/null 2>&1 ) ;;
esac
fi
done
fi ########################################## second added line

With this modification to initrd.gz, we could change the backup routine
to save update.tar.gz to /mnt-system/KNOPPIX/, and leave it there.
It would be activated only by the cheatcode "restore" and the update
could remain in place and not require moving it around.

My post #5 has a syntax error in the init of minirt.gz.

line 744 "fi" unexpected (expected "then")

What a grand way to demonstrate a syntax error.

Here's an example the magic required to edit the init in minirt.gz
The really crucial lines are spaced apart from the others.

cd /
sudo su
mkdir fresh_tmp # because you need a clean workplace
cp /mnt-system/boot/syslinux/minirt.gz /fresh_tmp
cd fresh_tmp
gunzip minirt.gz

cpio -imvd --no-absolute-filenames -I minirt

sudo leafpad init
( here we change init and save )
rm minirt # you don't want this in the gzip process

find . | cpio --quiet -o -H newc | gzip -9 > minirt.gz

chmod +x minirt.gz # because the original was executable
cd /mnt-system/boot/syslinux
mv minirt.gz minirt.gz.orig # this may come in handy
cd /fresh_tmp
mv minirt.gz /mnt-system/boot/syslinux
( here we should probably erase our tracks in fresh_tmp
before it becomes a permanent fixture )

Be aware, any syntax error in init will bring your boot process
to a screeching halt. As I have just demonstrated.

It may be noted that the technique of post #1 comes in handy in
cases like this.
I will now belatedly study compound if/then syntax. More later.

Good! The simplest way to distribute it, may be to take diffs of the original and modified init. Also, if you use grub, you may setup different directories each with their own minirt.gz, and switch between them, to test out modifications/features.

Line 734 of my modified init of minirt.gz was missing a ';' after the test
condition. So here's where we are relative to my post #1.

1. Define a backup routine that, on command, saves a compressed copy of
/KNOPPIX-DATA in /mnt-system/KNOPPIX, as opposed to /mnt-system.

2. Redefine the init of minirt.gz to acknowledge a new cheatcode 'restore'
that is required to access the stanza which applies updates found in the
KNOPPIX directory. Only two new lines are needed.

3. Occasionaly command a backup to provide for a subsequent restore;
when needed, at start-up, include 'restore' as a cheatcode.

4. A LiveCD, although handy to have around, will not generally be required
to move the 'update' from one location to another.


Here are some loose ends for the purists:

1. Inexplicably, my minirt.gz, although now more capable in my estimation,
is actually smaller than the original. Go figure.

2. The backup program and my mods to the init of minitrt.gz are pretty ho-hum
in themselves, but there are two new cpio commands essential to this process
which I have deduced from old debian-knoppix graffiti. I hope I have applied
these correctly. I can't say I understand these details at this point.

3. In my use of this technique, I only use about half the available space
that's available. It would probably be advisable to add some code to test for
available storage before carrying out both backup and restore operations.

Do you think you could find time to write this up for the documentation wiki here? I think it should be updated, perhaps a separate version for 6.X written. Also, it would be nice to present the different modifications as a set of patches to alpply to /init, organized so that they may be applied independently, if possible.

That's probably over-kill; there doesn't seem to be much
traffic on this idea.
Also, I'd like to get more comfortable with the 'restore'
option by using it for some time.
I would like to see a professional discussion of minirt.gz
and how to adapt it to some new purposes.
Also, I must be a minority of one that likes the challenge
of getting a 2 Gb LiveUSB setup to do things.

That's entirely up to you. The reason I suggested this, is that most of the more "evolved" modification ideas involve minirt.gz and /init. Including yours, I think I know about 5-7 modifications, which could be implemented as patches.

Using a 2 GB liveUSB surely belongs to the sports department these days, yes, but that does not make it uninteresting. Rather the contrary, it is very useful for proofs of concept. And BTW, to create a pure 64 bits Knoppix we should probably start with the CD package selection, and stay around there until issues are resolved satisfactorily. Also, for pure forensic purposes, the CD size install is the best, I think.

Thanks for your comments.
I'll have to find and review those other minirt offerings.
I can remember Forester doing some squash things, but I
never understood why, let alone how.
________

I know the Knoppix CD has a 64-bit kernel option,
but I thought I'd heard it's very light on 64-bit apps.

Even tho' my machine is 64-bits, I stay with 32-bit apps just
to avoid any 64-bit hassles. I'm obviously not a power-user;
I just want things to work.

My Windows 7 is 64-bits, but my major app is Open/LibreOffice,
and the 32-bit version is smarter than I am. Works just as
well on 2 Gb 32-bit Knoppix as 350 Gb 64-bit Win7 for what I do.

Quote:

---

Originally Posted by utu

I know the Knoppix CD has a 64-bit kernel option,
but I thought I'd heard it's very light on 64-bit apps.

Even tho' my machine is 64-bits, I stay with 32-bit apps just
to avoid any 64-bit hassles. I'm obviously not a power-user;
I just want things to work.

My Windows 7 is 64-bits, but my major app is Open/LibreOffice,
and the 32-bit version is smarter than I am. Works just as
well on 2 Gb 32-bit Knoppix as 350 Gb 64-bit Win7 for what I do.

---

Yes, in your case you can safely stay with 32-bits. But you may try out running with 64-bits kernel. That has helped me in a number of situations.

64-bits today is mostly for special things, like computing on 4GB data arrays etc. But when you need it, you often need it badly, which is why I would like to get a pure 64-bits Knoppix.