Back up Save file........Possible?

[DaveS]

So......... frugal install to hard drive. Puppy 4.2*. All files on hard drive, no boot CD.
Is it possible to back up the save file from within the operating system while it is running? I have tried, but the backup reports errors when run. I have to create the backup using a live CD or alternate Puppy. Is there a way to avoid this please?

[mikeb]

yes it probably will.How are you backing up..copying / gzipping the pup_save file or internally?
What about using the remaster script (or dougals cause can just make an sfs then) as a form of backup. Then restoring your setup would simply be a case of running a fresh frugal install.

mike

[DaveS]

yes it probably will.How are you backing up..copying / gzipping the pup_save file or internally?
What about using the remaster script (or dougals cause can just make an sfs then) as a form of backup. Then restoring your setup would simply be a case of running a fresh frugal install.

mike

Just simple drag and drop 'copy'

[rcrsn51]

If you are booting from GRUB, add another menu option that launches Puppy with the "pfix=ram" argument. Then mount the Puppy partition and do the backup. I like to use:

Code: Select all

gzip < pup_save.2fs > pup_save.gz

[mikeb]

Just simple drag and drop 'copy'

Rox doesn't get on well with this type of operation
one problem would be whiteout and other hidden files.
cp in a terminal would probably work better eg

cp -r /initrd/pup_rw/* /path/to/backup/folder/

mike

yep that works..just tested it
then archive the folder
make sure your backup folder is on an ext2 or ext3 partition and outside of the pup_save

[DaveS]

Thanks Mike, but I dont think that gives me quite what I want. I am looking for a way to effectively create a copy _save.sfs file while the op system is running. If I do this, the resulting file gives errors and wont load.

[DaveS]

If you are booting from GRUB, add another menu option that launches Puppy with the "pfix=ram" argument. Then mount the Puppy partition and do the backup. I like to use:

Code: Select all

gzip < pup_save.2fs > pup_save.gz

Thanks for this too, but I can easily do this from outside the running op system just by booting another Puppy version. I just wondered if it could be done from within.......

[mikeb]

Ah just realised ..what errors are you reporting??

When running certain files are created and then removed/changed at shutdown....If you make a live copy then you will get the same problem as if the plug was pulled from your machine..boot errors..some tiding up would be needed

mike

[PaulBx1]

I have to create the backup using a live CD or alternate Puppy. Is there a way to avoid this please?

Copying the pupsave when using it is not such a good idea, but there is a way to avoid booting the live CD or alternate Puppy (whatever that means )

I have modified my /etc/rc.d/rc.shutdown script to backup as I shut down, so I don't have to reboot to backup. It's done as follows:

In that file, find this code at the end:

Code: Select all

#v2.16rc try this too... SAVE_LAYER defined in /etc/rc.d/PUPSTATE...
if [ "$SAVE_LAYER" ];then
 sync
 SAVEDEV="`mount | grep "/initrd${SAVE_LAYER}" | cut -f 1 -d ' '`"
 SAVEFS="`mount | grep "/initrd${SAVE_LAYER}" | cut -f 5 -d ' '`"
 busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER} 2>/dev/null
 umount-FULL -i -n -l /initrd/${SAVE_LAYER} 2>/dev/null #-l is lazy unmount.
fi

Replace it with this:

Code: Select all

#v2.16rc try this too... SAVE_LAYER defined in /etc/rc.d/PUPSTATE...
if [ "$SAVE_LAYER" ];then
 sync
 SAVEDEV="`mount | grep "/initrd${SAVE_LAYER}" | cut -f 1 -d ' '`"
 SAVEFS="`mount | grep "/initrd${SAVE_LAYER}" | cut -f 5 -d ' '`"
 busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER} 2>/dev/null
 umount-FULL -i -n -l /initrd/${SAVE_LAYER} 2>/dev/null #-l is lazy unmount.
 if [ -f /etc/rc.d/PUPBACKUP ]; then	# Execute PUPBACKUP to specify backup info if available
  . /etc/rc.d/PUPBACKUP
 fi
 if [ "$PUPSAVEBACKUPDIR" ]; then	# A backup directory specified in PUPBACKUP?
  echo -n "Back up your pupsave to ${PUPSAVEBACKUPDIR}? : " > /dev/console
  read -t 20 response
  if [ "$?" = "0" ]; then			# User responded in timeout period?
   if [ "$response" = "y" ]; then	# User responded with "y"?
    mkdir -p $PUPSAVEBACKUPDIR
    while [ $PUPSAVEBACKUPCOUNT -gt 0 ]; do		# Shift older backup files a notch
     mv ${PUPSAVEBACKUPDIR}${SAVEFILE}$[ PUPSAVEBACKUPCOUNT - 1 ] ${PUPSAVEBACKUPDIR}${SAVEFILE}${PUPSAVEBACKUPCOUNT}
     let PUPSAVEBACKUPCOUNT=PUPSAVEBACKUPCOUNT-1
    done
    echo "${SMNTPT}${SAVEPATH}${SAVEFILE} being copied to ${PUPSAVEBACKUPDIR}${SAVEFILE}0" > /dev/console
#    CURRENTPUPSAVE="/initrd$(losetup $(mount | grep pup_rw | grep -v union |cut -f 1 -d ' ') | cut -f 3 -d ' ')"
#   cp -a ${CURRENTPUPSAVE} ${PUPSAVEBACKUPDIR}${SAVEFILE}0
#   cp -a ${SMNTPT}${SAVEPATH}${SAVEFILE} ${PUPSAVEBACKUPDIR}${SAVEFILE}0
    cp -a /initrd/mnt/dev_save${SAVEFILE} ${PUPSAVEBACKUPDIR}${SAVEFILE}0
    sync
   fi
  fi
 fi
fi

Go into /etc/rc.d and create a file "PUPBACKUP" which has these contents, or something like it:

Code: Select all

PUPSAVEBACKUPDIR='/initrd/mnt/dev_save/backup/pupsaves'
PUPSAVEBACKUPCOUNT=3

Then create the directory you want to save your backup copies to, similar to mine at /initrd/mnt/dev_save/backup/pupsaves. When you shut down, it will ask if you want to backup. If you say "y", it will make a backup copy, and keeps several copies actually. If you say "n", or just ignore it (it will timeout in 20 seconds), it will simply shut down without creating any copies first.

Yeah, it's a bit crude, and not completely thought out (I'm not really sure how the shutdown script works, and not much of a coder either) but it does the job for me. I wish Barry would incorporate something like this in his new Puppies. Sure is a lot more convenient than the current system.

REMEMBER TO CREATE A BACKUP COPY OF YOUR PUPSAVE BEFORE CHANGING THIS SCRIPT. Otherwise, if you goof on editing, you may be in trouble.

[hillside]

PaulBx1,

That looks like a useful script. Too bad there isn't a way to save the file on demand instead of dealing with it on each shutdown.


I wonder how hard it would be to write an app that would
1. copy a backup of the pupsave
2. check your currently running pupsave for necessary information
3. Use the information from step 2 to "repair" or "cleanup" the backup so that it would boot properly if you needed to roll back to it.

This could be run from the menu whenever you felt the need to do a backup. For example, before you made an install of a new application that you might not have a lot of faith will install properly.

Currently, if I want to mess with an install that I'm not certain will work, I have to close out of Puppy, boot back up with a different Puppy or as pfix=ram, make my backup on the unused pupsave, close Puppy, and reboot into the original Puppy again. It's certainly do-able, but a simpler system would be nice.

[DaveS]

Hillside, that is kind of where I am at. Installing new software is not always a success, especially trying to get a non .pet app to work. When it goes wrong, I prefer to replace the _save file with a a version created prior to the attempted software install as I know it will be 'clean'. I guess I am using this something like the Wind$ Restore Point.

[rcrsn51]

I have the same situation as you. I use a separate partition for compiling and testing that has a modified init script. At bootup, it gives the option of restoring a pristine pup_save file. Read here for info on how to modify the init script.

Instead of inserting the code that is listed in that post, use the attachment below. You will also need to modify the top two lines to match your Puppy configuration.

There are four options:
Enter - boot with the current pup_save file
B - make a backup copy of the current pup_save
R - restore the backup copy
N - delete the current pup_save so you can create a new one

[musher0]

Hi, rcrsn51.

Hm... I haven't tried your code, but it looks ok. I don't know about other puppyists, but me, I sometimes have more than one pupsave file for a particular puppy. My positive criticism would be that in the code as it stands, you're limited to one filename:pup_save.sfs.

Would it be possible in bash code to introduce a third variable to be defined, such as PUPSV=pup_save-musher0_091010, for example. (I know such code would be a possibility in DOS.)

This would expand the user's choice of pupsave files.

Lines 9-11 would then become:

if [ "$CHOICE" = "b" ] && [ -f /mnt/data/$PFOLDER/$PUPSV.2fs ]; then
echo "Backing up pup_save.2fs to pup_save.bak..." > /dev/console
cp /mnt/data/$PFOLDER/$PUPSV.2fs /mnt/data/$PFOLDER/$PUPSV.bak

and similarly for the rest of the program. (The echo message would not need to be changed, since the user, having previously defined $PUPSV in the third line, would know which file he is processing.)

Respectfully,

[musher0]

This is what I use, however unsophisticated it may look like!

///////////////////////////////////
#!/bin/sh
# Nom du script : copderes-PupLin.sh
# automatic cleanup and semi-manual backup

# 1) nettoyage /cleanup
cd /root/.thumbnails/normal
rm *.png &

cd /root/.mozilla
rm -r * &

sleep 5

# 2) copie de réserve
cd /mnt/home/PupLin411rc
# the place of the active pup_save file
# IMPORTANT: replace this destination with your own
rox &

cd "/mnt/sdi2/_Linux/Toutou/pup4.12/09_01_27/"
# where the backup file is located
# IMPORTANT: replace this destination with your own
rox &
# 3) glide the active file to the backup place with the mouse.

# 4) make this script appear in the editor
cd ~/my-applications/Systeme
# IMPORTANT: replace this location with your own
geany copderes-PupLin.sh

# un-remark the following "cp" line in a text editor
# and re-run WHEN and IF you want
# an automatic back-up of the active file and
# a backup of the previous backup
# Re-remark the following line with a "#" to make it inactive again.
# cp -f -v --backup /mnt/home/PupLin411rc/pup_save-chr090110.2fs "/mnt/sdi2/_Linux/Toutou/pup4.12/09_01_27/"
# IMPORTANT: replace these disk locations with
# your own previously defined ones.

//////////////////////////////////

My two cents!

[diaeresis]

Hi musher0

I don't have a root/.thumbnails directory. I am using puppy 431. I am also using firefox not seamonkey so I suspect the root/mozilla directory might not be relevant, maybe something in root/.mozilla/firefox instead?

and rcrsn51
your set up actually looks as though it would be the most useful of the three suggestions offered for me.
I have tried and tried to make it work. but failed miserably.
The best I got to was the
Backing up pup_save.2fs to pup_save.bak...
message appearing but no actual copying was done.

i am using puppy 431 as I already said. I boot using the win n lin method which I believe is basically a frugal that boots from the harddrive rather than a cd. Because of this my directory structure seems to be very different to the structure outlined in your script.

I have sda1/mnt/home/puppy430/pupsave.2fs
/mnt/home also contains all my windows install, my menu.lst and both ntldr and grldr.

I tried modifying your script (shown below). I removed all the variables (possibly not the right word!) $XXXX and used actual locations. Among other changes. What is below got me to the
Backing up .....message.

Can you or anyone else possibly help me out with this as it seems so close but I just don't have the knowledge or ability to make it work.
Thanks


Original code from rcrsn51


#Modify the next two lines to match the target partition

PPARTITION="sda1"
PFOLDER="pup430" # or "." if at root of partition

mount /dev/$PPARTITION /mnt/data
echo -n "Press Enter-start B-backup R-restore N-new: " > /dev/console
read CHOICE
if [ "$CHOICE" = "b" ] && [ -f /mnt/data/$PFOLDER/pup_save.2fs ]; then
echo "Backing up pup_save.2fs to pup_save.bak..." > /dev/console
cp /mnt/data/$PFOLDER/pup_save.2fs /mnt/data/$PFOLDER/pup_save.bak
elif [ "$CHOICE" = "r" ] && [ -f /mnt/data/$PFOLDER/pup_save.bak ]; then
echo "Restoring pup_save.2fs from pup_save.bak..." > /dev/console
cp /mnt/data/$PFOLDER/pup_save.bak /mnt/data/$PFOLDER/pup_save.2fs
elif [ "$CHOICE" = "n" ]; then
echo "Starting with new pup_save..." > /dev/console
rm -f /mnt/data/$PFOLDER/pup_save.2fs
fi

umount /mnt/data


My stab at it


#Modify the next two lines to match the target partition

PPARTITION="sda1"
PFOLDER="pup430" # or "." if at root of partition

mount /dev/$PPARTITION
echo -n "Press Enter-start B-backup R-restore N-new: " > /dev/console
read CHOICE
if [ "$CHOICE" = "b" ]; then
echo "Backing up pup_save.2fs to pup_save.bak..." > /dev/console
cp /mnt/home/puppy430/pupsave.2fs /mnt/home/puppy430/pupsave.bak
elif [ "$CHOICE" = "r" ]; then
echo "Restoring pup_save.2fs from pup_save.bak..." > /dev/console
cp /mnt/home/puppy430/pupsave.bak /mnt/home/puppy430/pupsave.2fs
elif [ "$CHOICE" = "n" ]; then
echo "Starting with new pup_save..." > /dev/console
rm -f /mnt/home/puppy430/pupsave.2fs
fi

umount /dev/$PPARTITION

[musher0]

Hello, diaeresis (and other who might read this)

Actually, the #1) item in my script above should be removed completely if ROX-Filer is not using a "/root/.thumbnails" directory.

As to not having a "/root/.thumbnails" file in Puppy 4.3.x, that's because this directory is created by the ROX-filer if you activate its "show thumbnails" feature under "Options" -> "thumbnails". If you've never used this feature, the directory probably will not have been created. To my knowledge, the "/root/.thumbnails" directory feature is a feature of the ROX-Filer, not of any particular Puppy.

As well, upon reflection, in my script above, I don't know why I wanted to remove the "/root/.mozilla" directory if I was using Firefox or Seamonkey. Tricky indeed. (Ouch! Probably my subconscious telling the entire world I am not such a great fan of Firefox, but rather of opera!)

In any case, there are ways to configure those FF and Seamonkey to clean up their cache upon closing the program, in the "preferences" sub-menu. So that part of my script should go too. Sorry about that.

As well, since any cached material takes space, the .thumbnails and .mozilla directories can be put outside the pupsave file altogether and symlinked back at their original place with an absolute symlink. That saves a lot of space, and as a bonus, if you do that, you can stop worrying about your pupsave file getting filled with cached material.

This symlinking trick I picked up from one of the older postings on the Puppy forum by "MU". "jrb" of Choice Puppy also mentions it as useful for storing the "/root/.opera" directory outside the pupsave file.

Another space-saving trick would be to locate and remove any other thumbnails generated by gqview, XnView or other picture viewing programs before you make your backup. You would not normally want to save any thumbnails in a backup file.

[diaeresis]

Hi Christian (if you prefer)

So, I played a bit and I don't see the purpose of any of your script except this line:-

cp -f -v --backup /mnt/home/puppy430/pupsave-eric.2fs /mnt/home/puppy430/pupsave-ericbak.2fs

(please feel free to explain as I would like to learn!)

This creates a working sfs file right next to the sfs file in use and at the next boot you get the option to use either the original or the bak as puppy automatically gives you the option to choose when it finds more than one sfs.

So imagine this:-

Start puppy knowing that you are about to embark on some actions with a very high bork risk.
Use the backup script (maybe from a menu option?) (maybe a splash screen comes up saying "don't touch the keys until I have disappeared" or something similar
(splash screen disappears )
Borking is done in whatever way you usually bork your system (installing bad program , doing something stupid, whatever).
Shutdown in humiliation/disgust.
Reboot and et voila option to use pupsave-bak.sfs allows you to go back to unborked state.
Also needed then is some mechanism whereby the borked pupsave.sfs is deleted, the pupsavebak.sfs is renamed to pupsave.sfs and next time backup script is run a new pupsavebak.sfs is created.

Perhaps this could be accomplished by saving the backup as pupsave-1.sfs and the next time you use the script it would be saved as pupsave-2.sfs, then pupsave-3.sfs etc.

This is all way past my ability. I am still at the level where 'echo hello'
fills me with awe and amazement.
But if you or anyone else reads this and thinks "I could do that" it would be a fantastic thing for puppy. I would love to help if anyone is prepared to try and make this work.

This gives an almost windows like system restore capability. Which is very useful.

[musher0]

Hello, diaeresis.

(Before I start: I suppose that, by "bork" and "un-borked", you mean "mess up" and "un-messed up"? Please confirm, as English is not my native language. I could not find this word in the translation dictionary)

The difference between my copy ("cp") line and yours is that yours create a backup file in the same directory as the original with a different name. Mine creates a backup file on another disk with the same filename as the original; if a backup file is already there, it renames it with a "*.2fs~" filename and then does the usual copy

You have only one backup file; in my case, the second time I use my script, I have two: the one with the same name, and a backup of the backup (a file with the name ending in ".2fs~"). Come to think of it, if you run your own script more than once, you'll probably have the double backup too.

You are saving your backup in the home directory, which means your backup file will show up as a possibility at startup time, and that it can be used immediately as a regular file if somehow your ordinary pupsave is messed up. That's an advantage. If my ordinary pupsave becomes unusable, I have to boot my Puppy from CD with pfix=ram and copy my backup to the place of my ordinary pupsave file, and reboot again in the regular way. Again an advantage for your solution.

As to your suggestion of a script to rename your backup file and remove it, I have two questions 1) "why a script?" 2) "why remove the backup file?"

Your solution is already a "natural" solution. If your original pupsave file becomes bad, you can boot with your backup immediately. Once in puppy, first thing you do is to manually copy your backup over to the regular file -- with the regular filename. That's it, you're safe again.

In my opinion, we don't need an automatic script at startup to do that in the case of Puppy. Foul-ups are very very rare in pupsave files, and you have already created your backup. Just refresh your backup file every 2-3 days AND before you install or change something major, and you should be ok.

A windows-type restore capacity requires a lot of disk space. With your solution, you already have a regular backup file and a backup of the backup: that should be enough. Besides, who needs to imitate windows?

My only other suggestion to you in this case would be to find another disk to make an additional backup of the pupsave file and of the Puppy system file. If your "home" disk itself goes bad, then you will have not lost anything - or maybe just a day's worth of work, which is very little, considering.

[diaeresis]

c'est foutu? messed up is close enough

I have worked out what the " " do round your copy command. And amended my script.

Stupid question:- Does using the " " rename the first back-up and then copy the original or does it copy the original and call it 2fs~ ?
I have tried google but without success so asking you!

Just renaming the back-up as soon as you boot works fine just as you suggested. Thank you for that reality check!

The only issue I have is that booting with the back-up.2fs gives me a X error as it seems X didn't do a clean shutdown.

This is obvious as the shutdown information would be saved to the original not the back-up. It would be interesting to know exactly what information x is looking for and be able to add it to the back-up after creating it.

As to giving things a windows feel...well...new users coming from windows need perhaps a little more familiarity than many committed linux users realise! I say this knowing full well that I now need to find my body armour and head for my bunker!
In all honesty, if this machine could function with xp at the speed it functions with puppy i would have given up with puppy 3 or 4 weeks ago! But that is a topic for another thread!

[musher0]

Hello, again, diaeresis!

You typically use the " " around a /directory/file-location if you are copying on a VFAT32 disk to a Windows directory that has spaces in its name.

Example : cp this.txt "/mnt/sda1/Program Files/"

Linux does not like spaces in filenames. If you need clarity to separate parts of a filename, in Linux you'd rather use a "_" instead of the space.

Example : cp ceci.txt /mnt/sda1/nouveau_toutou/

The quote signs do not do anything other than that.

In cp -f- -v --backup $THIS_DIRECTORY/$HERE/$FILE $THAT_DIRECTORY/$THERE/ (for example)

the -f is for "force"
the -v is for "verbose"
the --backup is for... "backup"!

The way I understand it, the above command
1) looks for an existing file with the particular name given in the command, in the destination directory

1a) if there is such a file with this name, it renames it by adding a "~" to the extension.

2) it does the requested copy of the file.

You say:
> The only issue I have is that booting with the back-up.2fs gives me a X error as it seems X didn't do a clean shutdown.

Obvious question: is your back-up.2fs file good? If it's not, that would explain the situation...

I know there are particular cheatcodes (pfix=clean, I think and maybe others) in Puppy that are very radical and supposed to repair a file, but I have never used them.

For the time being, I would suggest typing

puppy pfix=fsck

when your CD starts. Perhaps this command will give you a good result.

Usually, if you don't exit properly, -- for example, because there was a hydro blackout during a storm --, upon reboot, a rectangle will appear just before X is launched to ask you to a) continue by pressing enter or b) to go to the command line and type "xorgwizard" (without the quotes).

So, you could also try the solution in b) above.

You say:
> (..) users coming from windows need perhaps a little more familiarity (...)

Well, since Puppy distros usually come with the default jwm or even sometimes icemwm window manager, Puppy distros are very similar to windows 95 or 98 or ME. If you compare Puppy distros generally with more console-oriented distros such as INX or grml... then Puppy will look very familiar!

If you want something more like Vista, try last year's VestaPup (based on Puppy 3.01) or a current version of Ligh_House_Pup (not sure of the spelling). This last Puppy makes much use of the KDE window manager, and might look more "familair" for newcomers.

References
Vestapup 3.01:
http://linux.softpedia.com/get/System/O ... 9794.shtml

Lighthouse Pup
http://www.lhpup.org/

Bye for now!