a new & improved, self-contained Knoppix personal backup

[utu]

I am trying to put some distance between making a simple backup and
purging the persistent store. Most of the time, one can make a little backup
and not even think about re-doing persistence.

I'm glad to learn there are other ways to go about re-doing persistence, but
I don't have to do that very often. So here's my take on knoppix-data.img,
but I consider this somewhat a distraction from the thread itself.

To purge a failed knoppix-data.img, it must be un-mounted first, then deleted.

One way to achieve this is to launch another working linux system, such as your
LiveCD and to delete the knoppix-data.img on an inert LiveUSB.

The cheatcode 'noimage' used in launching a LiveUSB must keep its knoppix-data.img
from being mounted, allowing one to delete it by means of the LiveUSB, without
recourse to another linux system for this purpose. I've not used it, but I can
(now) appreciate its usefulness.

In either case, the purged LiveUSB should provide the opportunity to (re)establish
a persistent file at each boot, until such time as one has in fact been
established. However, re-establishing persistence in this way purges ALL
changes inherent in the purged knoppix-data.img, both personal material and
other material not contained in home/, root/, etc/ and syslinux.cfg.

The personal backup will re-instate only the personal material. Other material
must be additionally re-constituted. The original backup program cited earlier
backs up ALL of KNOPPIX-DATA, not just the personal material if that is desired.
The storage overhead for this is considerably more, and to my mind not as efficient
a use of resources as this later 'personal version'.

So long as the LiveUSB seems to be properly functioning, there is no need to
purge-and-replace knoppix-data.img. Personal backups may be performed over and over
without recourse to purging and re-establishing persistence so long as
the OS seems to be performing as it should.

[Werner P. Schulz]

Personal backups may be performed over and over
without recourse to purging and re-establishing persistence so long as
the OS seems to be performing as it should.

Full acknowledge. Therefore my proposal to insert a date-item
update$(date +'%m%d%y').tar.gz

[utu]

Hi, Werner

Not to belabor the point, but if the system sees a file is to be
saved with the same name as one already 'in situ' it asks if you
want to 'write over' the earlier file. I first became aware of
this when it seemed to spoil my status prompts.

Your idea allows making backups unique wrt DAYs. Making several
in a given day I still observe this phenomenon. I might prefer
to swap YEAR for HOUR, retaining the same brevity but allowing
for more changes per DAY of the medium.

[Werner P. Schulz]

... no problem

STOR=update$(date +'%m%d%H').tar.gz
or
STOR=update$(date +'%m%d-%H%M').tar.gz

[utu]

Further refinements to the personal backup idea.
.
I've incorporated all of Werner's excellent suggestions, and since
I found I never referred to the tar listing, that's been omitted.

In examining the remaining contributors to the 'personal backup', I found
that not only is .mozilla the real space hog, but its caches are its
biggest contributors. It is possible to clear at least one of these caches
with a quick trip to the IceWeasel Edit>Preferences GUI before making
a backup, resulting in a great reduction in the size of the stored file.

A revised listing is as follows:

#!/bin/bash
#
# new.backup2: do 'chmod +x new.backup2' & 'chown root:root new.backup2'
# Before backup, Go to Edit>Prefs on IceWeasel & 'Clear Now' the Off-Line cache.
#
cd /; STOR=/mnt-system/update$(date +'%m%d%H').tar.gz
echo -e 'Compressing data; patience, this may take a little time..\c'
tar -czf $STOR KNOPPIX-DATA/home/  KNOPPIX-DATA/etc/ \
               KNOPPIX-DATA/root/  mnt-system/boot/syslinux/syslinux.cfg 
echo '.Done.'; echo 'Restore using the command, tar -xzf '$STOR' -C /'
#
exit 0

Now if some clever person here will inform me of some appropriate API,
assuming there is one, we might automate that effort as well. This is
to say that I haven't been able to 'exclude' from the tar inclusion
the Cache & OfflineCache directories from ~/.mozilla/firefox/*.default/
which are the culprits I'd like to exclude.