Users upgrading to v1.3 should uninstall any previous version.
PHB no longer installs to /root/my-applications/bin. Files are now installed with Linux FSH in mind:
/usr/bin/pupsave-hot-backup
/usr/local/pupsave-hot-backup/phb_core
/usr/share/applications/Pupsave-hot-backup.desktop

The default save to location now matches the partition or partition/directory of the active pupsave.

*.4fs save files supported.

The backup button is now disabled while a backup is in progress and also during the following error conditions:
1) Trying to backup to the active pupsave file.
2) The storage device is not mounted.
3) The chosen file is not a valid pupsave file (*.2fs, *.3fs, *.4fs.)
4) Not enough free disk space. (file size + 100 MB required).

Added a safety catch and popup notice if more than one backup for the same file is started before the backup name auto-regenerates (regeneration is every 60 seconds).

Code changes to prevent 'NOT ENOUGH DISK SPACE' from displaying while a backup is in progress. This would happen if a 1024 MB save file was backed up to a 1500 MB partition when the free space dropped below 1124 MB. Harmless, but kind of disconcerting.

Work-around to prevent JWM from freezing when running from a JWM menu in Lupu 5.28.

Bugfix: File named '0' no longer continuously created when using Bash 4.1.

Bug fixes:
Fixed orphaned processes after program close.
Fixed bug that would only allow save locations to two directory levels in newer Puppies.
Removed non-functioning close button in the help window.
Misc code improvements

A tiny gtkdialog utility for backing up the live pupsave file. You no longer need to reboot with pfix=ram in order to backup the savefile. Lots of built-ins and safety features make it very "oops" proof.

Auto-detects the current savefile.
Generates the backup file name with the date and time appended.
Checks the available space for the backup file.
Will not perform the backup if anything is incorrect.
Displays real-time status and progress feedback.
Supports 2fs and 3fs save file types.

Yeah, deleting all of my code comments would knock a chunk out of it too

@seaside
Caution noted. Common sense applies here. As noted in the help dialog, shut down all of your apps before running the backup. I have been backing up in just this manner for about a year now using a hard coded script without any problems whatsoever. Also the utility runs e2fsck on the backup as a safety measure and doesn't need pfix=fsck on the next boot.

Speaking from experience, installing software or trying a new version of Puppy is much more dangerous to your savefile.
._________________﻿

Heh, this has got me thinking about how to do a proper hot-backup, but all methods are vastly more complicated than pfix=ram.

I think if you are using pupmode 13, you're safe copying the 2fs file as long as it's not currently saving. The RAM layer should prevent block-level filesystem corruption, but maybe not logical corruption (if one of your apps was in the middle of an update when the last save occured).

However you need to be aware that the backup will only be current up to the last save.

There is one thing that got me wondering about the pupsave file size.
If you set up a 2 gig pupsave with the increase pupsave.2fs size and then do a Hot Backup of your pupsave file, is the free space preserved?
In other words, when Hot Backup creates a new ext2 file for copying the contents of your pupsave.sfs file to, how does it know how big to make the destination file?
Maybe that is a dumb question, but I had to ask.

I did try running an e2fsck on the backed up pupsave file that was created and it comes out clean.
My desktop widget for Puppy Space shows 1.72gig -443.18 Mib.
It previously showed 1.72gig - 800 Mib before I did an e2fsck of it from outside of it. In other words, it was not in use.
The created backup pupsave was 1.79 gig.

So I guess my main question is to if the original size of the pupsave file is preserved?

ambushcrafter,
What Puppy version are you using it on?
Also, do you have any Desktop Widgets running that access information from the internet?
Any application that involves writes other than Hot Backup should not be running.

As to the bug, I also noticed that the "Done" message does not stay up.
This is due to a few lines of code that first write the word "Done" to a temporary file to be displayed, then a line that waits a specified period of time, and finally writes "" to the temporary file.
I have to agree that would be good to change to be persistent after the backup completed and cleaned up on exit from the program.

i just copy mine while it is mounted and in use, both for live ssd and semi-live SD. never had problems. do a click target save immediately before the semi-live pupsave save. all are 32mb minimums containing only narcissistic mods, so what can i lose anyway. anything that is not absolutely necessarily in the pupsave isn't in there. works for me._________________
ASUS EeePC Flare series 1025C 4x Intel Atom N2800 @ 1.86GHz RAM 2063MB 800x600p ATA 320G
_-¤-_<º))))><.¸¸.•´¯`•.#.•´¯`•.¸¸. ><((((º>

Posted: Mon 15 Feb 2010, 02:31 Post subject:
backupsSubject description: here is how i do it

Backing up is a Good Thing - so much easier than trying to sort out the mess otherwise when something goes wrong.

So I install two puppies on every machine which I use or setup. One is the 'working' puppy and the other is intended only to allow backups to be made.

I usually create a separate partition for the backups of say 3gig. Booting into the first puppy which i call 'setup and backup' allows me to backup the other installation of puppy while it is not running. For extra peace of mind also back up the puppy which allows me to backup the 'working' puppy. And making a backup copy of the backup is a natural extension of this exercise! I love the frugal installation option because it does make a complete backup so easy - only one file to copy.

I am curios though as to if just copying the Pupsave file to a new location as a backup fixes a corrupt file system in it.
If you run e2fsck on the pupsave file backed up (by the copy method),
does e2fsck report it as clean?
Using Hot Backup to create a dated backup of the pupsave file does report it is clean using e2fsck.
All it takes for my pupsave file I am using to have e2fkck report stuff that needs fixing is to reboot to another Puppy and check the file.
And if I do it a number of times switching back and forth between booted versions, it seems the pupsave file never really gets unmounted cleanly.
I am open to arguments on this and a remedy.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum