Puppy Linux Discussion Forum

Pupsave-restore can restore backups created by Pupsave Backup:
-un-compressed or compressed savefile backups
-compressed savefolder backups

Requires YAD, already installed on most modern Pups.

It was created as a result of the discussion here:
viewtopic.php?t=13648

This release will only work if your savefile or savefolder is stored and used in the main Puppy
install directory.

Has only been tested on a couple of Pups, so proceed with caution.

You can use the .pet file to install and have a menu entry in Utility or just download the script
if you want to try it or look at the code (it's not pretty).

Revision 250126
Version 3 now gives users a choice to add to the restore name.

wizard

@wizard :-

Well; you're right. It ain't pretty!

I don't think I've ever seen YAD used quite like that before..! That wee "niggle" notwithstanding - - if it does what it's supposed to, who CARES what the hell the code looks like. The main thing is that it works, right?

(My own coding is an unholy mess, I'll be the first to admit! I know I don't use 'accepted' layouts (whatever that means). What constitutes an 'accepted' layout? I use bits'n'pieces of code from here, there and everywhere, snippets I've picked up from all over the place.....and fragments of different layouts I've seen in scores of different places over the years. But that's the beauty of being a hobby coder; you can get away with stuff that you probably couldn't when working as part of a team, since everybody has to sing from the same hymnsheet in that situation.....or else nobody understands what the other team members have written, or are talking about!)

==============================

That thread you've referenced got more than just you thinking, y'know. Having demo'd that wee vid clip showing my own backup set-up - and having got a remark from @greengeek to the effect of 'was I planning to formalise my scripts' ( ) .....along with the response I gave him - I too began head-scratching, and wondering if I could put together a simple utility for basic 'backing-up' AND 'restoring'.

I've been messing about with it most of the afternoon & evening. Finished up about 3 hours ago - packaged as a 'portable', of course! - and sent Ian a copy for testing, since he'd kinda "challenged" me to do so.....

Mine is based more or less around copy/paste, and utilises the YAD file-chooser dialog to let the user choose exactly what they want to copy OR restore, AND where they want it to go. I'll wait and see what Ian thinks of it, then I'll probably publish it after that. We'll see; it works well enough for ME, though whether other folks can live with my particular design "choices" is anybody's guess..!

Mike.

@mikewalsh

That thread you've referenced got more than just you thinking, y'know

Yep, about 3 years ago when I was doing all the beginners howto doc's, realised we didn't have an easy restore method for Pupsave backups. Was just starting to do interactive bash using Xdialog, so took a crack at it then, but found Xdialog didn't have the power for the job. Let it slide until now. Pupsave Backup has always worked well for me, so figured we just needed the restore piece. As you know, YAD can do some pretty fancy stuff.

Thanks
wizard

Now you know why malware, viruses, root kits, etc...... leave Puppy Linux alone.

They take a look at the code used in Puppy programs and think: "This thing is already full of this stuff, someone has already gotten here ahead of us"

Nothing in it is normal Linux coding.

Wast of time trying to add to what is already infecting this operating system.

Reading the OP: "ONLY works ..."

Does this PET work if save-folder is stored within a folder on a system-drive partition (for example folder-named "Sessions")?

Curious

wizard wrote: Sat Jan 25, 2025 2:54 am

@mikewalsh

That thread you've referenced got more than just you thinking, y'know

Yep, about 3 years ago when I was doing all the beginners howto doc's, realised we didn't have an easy restore method for Pupsave backups. Was just starting to do interactive bash using Xdialog, so took a crack at it then, but found Xdialog didn't have the power for the job. Let it slide until now. Pupsave Backup has always worked well for me, so figured we just needed the restore piece. As you know, YAD can do some pretty fancy stuff.

@wizard :-

Hm. I would hazard a guess that the majority of those Puppians who DO regularly code, create/modify stuff, whatever, are all "self-taught". Highly unlikely that many of us have received any kind of formal training, either.

I DO accept that if you go back 20 yrs ago to the dawn of Puppy, the available resources on most hardware of the time meant you needed to keep code lean & tight, 'cos there wasn't the computing power available to do that much with it. I can READ code, despite that I don't always understand what it's doing.....but I'm getting better at it, as I research more & more stuff in the course of my "projects". One thing IS certain, though; doesn't matter if you have 128 MB of RAM or 128 GB of the stuff, a line of code still occupies the same number of bytes now as it did way back then. That much hasn't changed.

To me, Bash is certainly about the easiest scripting language for hobby coders to get their head around. It's universal; every distro has it baked-in.....and it's fairly forgiving, too, once you understand the relatively few basic "rules of the game".

========================

I'm a big fan of YAD myself (and credit must go here to Smokey01 for his magnificent on-line tutorial. Grant did a lovely job with that!)

Oh, I've experimented with gtk-dialog, and yes; I understand those who say "Why install another dialog-creation tool when Puppy has one built-in to start with?" I'm sorry, but to me, YAD is far easier to pick-up the basics of and to start achieving results with. Gtk-dialog is incredibly fussy, and needs several lines to do something that YAD can often achieve in one.....

Still, at the end of the day, it all comes down to personal preferences. You use what you're happy using, what you're familiar with, and what produces the results you're after. Despite dire predictions, I don't think Puppy's in any danger of dying any time soon.....and we'll always have our crew of community coders. I don't see THAT changing, either.

(*shrug...*)

Mike.

@mikewalsh

YAD is far easier to pick-up the basics of and to start achieving results with. Gtk-dialog is incredibly fussy, and needs several lines to do something that YAD can often achieve in one.....

Same choice for me, Gtk-dialog more powerful and detailed, but Yad has been much easier and faster for my little stuff.

Thanks
wizard

@bigpup

They take a look at the code used in Puppy programs and think: "This thing is already full of this stuff, someone has already gotten here ahead of us"

Thanks for the great laugh

wizard

@Clarity

Reading the OP: "ONLY works ..."

Does this PET work if save-folder is stored within a folder on a system-drive partition (for example folder-named "Sessions")?
Curious

Nope, this release only works if the saves & backups are both in the same directory as the main install (initrd.gz and other .sfs system files). This would be the most common standard setup for new and casual users.

Thanks
wizard

@mikewalsh

I don't think I've ever seen YAD used quite like that before..!

Guess you are referring to how the YAD statements are built. Easier for me to build and troubleshoot if they are columnar rather than linear, especially if they are long or complex. Example:

yad -- title "Example" --width= 100 --height=100 --button=Yes:1 --button=No:2 --button=Maybe:3 --text "Boy this is starting to all run together and makes it hard for wizard to see what's going on when things don't go right or if it's late at night or wizard has been drinking!"

As opposed to:

yad -- title "Example" \
--width= 100 \
--height=100 \
--button=Yes:1 \
--button=No:2 \
--button=Maybe:3 \
--text "wizard can mostly read this and see what's going on when things don't go right or if it's late at night
or wizard has been drinking!"

Just a mental thing.

wizard

See first post for 250125 improved version.

wizard

Thanks @wizard

wizard wrote: Sat Jan 25, 2025 1:59 pm

@Clarity

Reading the OP: "ONLY works ..."

Does this PET work if save-folder is stored within a folder on a system-drive partition (for example folder-named "Sessions")?
Curious

Nope, this release only works if the saves & backups are both in the same directory as the main install (initrd.gz and other .sfs system files). This would be the most common standard setup for new and casual users.

Thanks
wizard

This ONLY considers a forcing of user to INSTALL a WoofCE distro. Many members come here using VEntoy/SG2D for ISO booting. This technology of ISO booting has been present for years across the forum.

Thus, as this PupSave was done years ago and now a restore feature is added, "I think", a best practice would be the ability to use backup and restore to the location of the save within the Sessions folder no matter where it is resides... not limited to where it is presently targeted in only that location.

Restore is a good feature to add, but, we might consider the modern times where, for whatever the rationale the user chooses for original session placement, it should be honored with that option for session location in, both, backing up and restoring from.

Thoughts

I can also think of many corner cases for various types of puppy installs or user preferences, but I hesitate to ask for features without knowing the project's scope especially if I cannot contribute the code.

This conversation with Clarity reminds me of working in a research group. I remember demonstrating a special case system I had developed; my supervisor was delighted with it, but immediately instructed me that to finish it off I needed to define the work in a non-specific more general purpose way. In a similar sense an early stab at creating a utility app will always just be for a special limited case scenario.

However, a utility app will 'eventually' (depending on its creators time/feeling) take into account related overall operation and facilities provided by the system such that the utility app could reasonably be called a fully polished utility app. So if the main system provides ability to place save folders anywhere then utilities involving save folders would hopefully eventually respect all such underlying distro functionality and account for it.

It is maybe good that a caveat placed in any utility app description indicating when such full support of possible system installation methods is not yet complete and indicating what doesn't function yet; in this case Ventoy and similar iso boot save Session support, which (I expect) a minority but nevertheless fair number of people probably use.

i.e. the 'ideal' utility app supports all related underlying system mechanisms, but in this case the utility app is probably useful for the majority of users, just not Ventoy, or sometimes other iso boot mechanisms, including some boot mechanisms that might be popular for Qemu.

Sorry, I'll stick to my 'manual' back-up method.

A SaveFolder is just a folder with a specific name Puppys instructions look for adjacent to the 'core.sfs' --e.g.puppy_dpupbw64_10.0.9]-- on boot-up and if present will mount. If two or more SaveFolders --e.g. i]e.g.[/i] dpupbw64save-dec19] and i]e.g.[/i] dpupbw64save-video]-- are found, boot-up will be interrupted, and the User will be prompted to choose between them and booting wihtout mounting any.

All my grub/grub2 menus offer the alternatives of booting into Puppy without mounting any Save. Having done so I can Right-Click a SaveFolder and choose Duplicate* from the Pop-Up menu, giving the duplicate a different suffix than the original. Without changing the new SaveFolder's location, I can now boot into either SaveFolder and modify it. Or I can boot using one, and Right-Click the other and select dir2targz or use packit from the main-menu to compress it, moving it werever I want. Compressed, it is easy to transfer to a different computer or anywhere else along with a Puppy's system files.

Even if the boot-menu does not offer to boot without using a Save, creating a properly located folder with the designated tname --e.g. dpupbw64save-FALSE-- and rebooting will trigger the option to choose which or no Save to use.

"Restoring a back-up' merely consists of decompressing the tar.gz and moving it into the right-location. With a different name it will happily co-exist with the other SaveFolder until I'm satisfied that all is well.

It should be mentione that nicOS-Utility-Suite, viewtopic.php?p=127314#p127314 includes a module to generate a SaveFile from a SaveFolder. See https://oldforum.puppylinux.com/viewtopic.php?t=96472 if you want to obtain a SaveFolder if you have a SaveFile. SaveFiles are easily copied/moved and can be stored anywhere. They also follow the same naming convention.

-=-=-=-=-=-
* In the absence of Duplicate on the Right-Click Menu, SaveFile/Folders can be copied if you are operating without having mounted them.

@mikeslr

Keep in mind who will be glad to have a GUI restore utility, new and casual users.

Pretty sure you qualify as an advanced user , and once you understand how that part of Puppy works you can do great stuff by have having multiple savefile/folder configurations. Lots of my installs are manual including the Grub entries. Rather than make a separate Grub entry to boot without a savefile/folder, you can go to the install directory and just make a zero byte savefile/folder (just name it accordingly, mine include the word DUMMY). That file triggers the save choice menu during boot and you can choose boot without save there also.

wizard

@mikeslr :-

Yeah, I used to swear by save-files for that very reason.....until I found them growing ever larger & more bloated, and ended up having to enlarge them again.....and again.....AND again... You get the picture, I think!

I think my record was the one I had under ETP's 'ChromebookPup v1'. Ran out at a tad under 17 GB toward the end... But one thing's undeniable; the things are certainly a sight easier to back-up and move around, that's for sure.

====================================

@wizard :-

wizard wrote: Sat Jan 25, 2025 1:59 pm

@Clarity

Reading the OP: "ONLY works ..."

Does this PET work if save-folder is stored within a folder on a system-drive partition (for example folder-named "Sessions")?
Curious

Nope, this release only works if the saves & backups are both in the same directory as the main install (initrd.gz and other .sfs system files). This would be the most common standard setup for new and casual users.

This is why the test example I sent greengeek to try-out uses the YAD file-chooser dialog 'switch'. You're not limited to whatever locations you've "hard-coded" into the script, and can vary the location of what you're backing-up, along with the destination you want to send it to.

At Ian's request, I've added a 3rd option; not just backing up a frugal install OR a save-file/folder, you can now choose to use it for simply backing-up directories of personal data. I'll pack that up & send it to him for evaluation in a little bit.....once I get Mama settled for the night!

(I only started using the file-chooser option myself quite recently, so it's still a bit new to me, too. Makes selecting files'n'stuff SO much easier, though...)

Mike.

@mikewalsh

You're not limited to whatever locations you've "hard-coded" into the script

Not actually "hard-coded", rather it is retrieved from the /etc/rc.d/PUPSTATE file, so it works with any drive/location where Puppy was booted.

wizard

As I discussed this backup utility before, and NOW, I 'may' have mis-understood @wizard.

In his last post to this thread, he is indicating that this 'respects' the WoofCE feature of PUPSTATE which supports use of the SAVEFILE in the boot-location!

The SAVEFILE and/or shutdown-processing which established session-save location, is where the session is current.

My questioning on the thread has been to bring attention that the utility, "as stated" is NOT going to backup/restore a save in the session folder, by design. Again, this is how I understand the description presented.

@mikewalsh offers an acceptable GUI while @mikeslr offering a terminal command line approach such that the user(s) has control of the location of backup.

In my case, and my case only, I keep ALL of my backups on a partition on my LAN in a folder named "Backups". This is my way of housekeeping and knowing what/where they are for restore when need.

FYI

A good idea having one program that allows you to select make a backup or restore a backup.

But I really do not like using the word restore.

---------------------------------------------------------------------------------------------------------------------------------------------

If the backup save was compressed when it was made.

The restore option does change it into an UN-compressed backup and give it an added name RESTORED.
But it is still the backup save made at a specific point in time. That information is no longer in the name. Date it was made.

I fear someone is going to think they just restored the old broken save and using this save labeled RESTORED will have everything that was in the broken save.

Which it will not.

-----------------------------------------------------------------------------------------------------------------

When the restore option is used on a not compressed save.

All it is doing is deleting the .BKP and date time info from the name of the backup save.

Change the name to save name-RESTORED.

No more information on it still being a backup made at this specific date.

I fear someone is going to think they just restored the old broken save and using this save labeled RESTORED will have everything that was in the broken save.

Which it will not.

------------------------------------------------------------------------------------------------------------------------------
Look at this with several saves present that this program has provided.

Took original save and did normal backup and a compressed backup.

Took the normal backup save and selected restore.

It just renamed the backup with now only added -REDTORED to the name and no date time info.

I used restore option on the compressed backup.

It UN-compressed it and gave it the same name that was already being used, when I restored the not compressed backup save.

So it replaced that restored backup and it is not there anymore as another restored labeled backup..
.

.
.
The only thing close to restoring is UN-compressing a compressed backup save, so it can now be used as a save to boot with.
Restoring it to a usable UN-compressed state.
.
.
--------------------------------------------------------------------------------------------------------------------------------------------------

The restore option is making a copy of the backup selected to restore.

So now have two of the same backup save.

Well, never can have too many backups.

But again, no date time label on the RESTORED one, no idea restored from what?
.

The only thing close to restoring is UN-compressing a compressed backup save, so it can now be used as a save to boot with.

uncompressing and not deleting the compressed backup should be the action, retaining the compressed backup for another day. Other wise the program would have to explain restoring is a one shot deal which I think is kinda quirky.

All backups should be compressed automatically when made. If a user wants to go in and delete uneeded backups thats ok. I hesitate to suggest this app should incorporate a backupmanager, but if it is within the scope of the project it would be a nice addition.

this does not preclude the user keeping an alternative uncompressed save.

alternative and backup are two different things really. and one could always back-up an alternative save

but really this deliberate elimination of the choice to compress or not is a subject that should be addressed here but rather in the other thread, as the backup button just calls the other script

@Clarity

the utility, "as stated" is NOT going to backup/restore a save in the session folder, by design. Again, this is how I understand the description presented.

Once again, that is correct, plainly stated when the program runs. It means there are some minority use cases where it currently will not work, Ventoy is one of them.

Currently Puppy has no standard backup restore program, and having one would be a worthy addition. Pupsave-restore, if nothing else, is a proof-of-concept. It's a first release (now 2nd) and it's aimed at helping new and casual users.

Advanced users like yourself have the skill and knowledge to manually rename or extract and rename a backup file, so it's not a stumbling block like it is for those who don't.

Your particular configuration, which works for you, is also complex and a little convoluted compared to a plain Puppy install. Not sure you should expect coders to write for that use case.

Thanks
wizard

@bigpup

Ah, come on Biggy, it's a first (now 2nd) release and a work in progress.

wizard's rule #15 "The greatest leap in capability is the one between NOTHING and SOMETHING

But I really do not like using the word restore.

Not sure about that one since "restore" is the standard terminology in the computer world.

It just renamed the backup with now only added -REDTORED to the name and no date time info.

"REDTORED" Nah, don't think it did that

One point of clarification is Pupsave-restore always leaves the original backup in place.

Most of the rest of what you listed can be addressed by release 3, which gives the user the ability to add to the restore name.

Do appreciate you checking it out, watch for 3.

Thanks
wizard

See first post for 250126 improved version 3 which adds user restore naming.

wizard

I'd agree with some opinions posted here that the extracted pupsave folder should better have the <timestamp> addition same as the compressed archive name originally has.

EDIT; Btw, the pupsave-backup mod from me here: viewtopic.php?p=141190#p141190 does create a save folder name with <timestamp> added inside the archive when chosen for compressed backup.

wizard wrote: Tue Jan 28, 2025 2:22 pm

See first post for 250126 improved version 3 which adds user restore naming.

wizard

works with vanilladpup 10.

appending to the folder name is nice, but should one be able to just rename as desired without retaining the originalname+RESTORED?

perhaps ask for a new name and a yad message if there is already a save with the same name? (nothing wrong with the way it is now really, just thinking out loud here)

@williwaw

appending to the folder name is nice, but should one be able to just rename as desired without retaining the originalname+RESTORED?

Thought about that, but then the restore loses any reference to its origin, think its certainly better for inexperienced users to leave as is. Of course anyone can edit the name to whatever after the restore is complete.

Thanks
wizard

Using v3 of Pupsave Restore Backups

Any program needs to be fully tested to make it a well developed program.

So I am reporting as a tester.

BookwormPup64 10.0.9 with two save backups.
One compressed and one UN-compressed.

Got this when selected to do restore, the selection window.
Notice it has upper and work in the list.
Those are the directories in a save.
.

.
.
When I tried to do the restore on the UN-compressed save backup (a backup save folder)
It did nothing and this was displayed in the terminal.
The 20250105 was what I tried to add to the name of the restored.
.

wizard wrote: Sun Jan 26, 2025 11:48 pm

@mikewalsh

You're not limited to whatever locations you've "hard-coded" into the script

Not actually "hard-coded", rather it is retrieved from the /etc/rc.d/PUPSTATE file, so it works with any drive/location where Puppy was booted.

wizard

@wizard :-

Ah. OK; yeah, I'm with you.

The backup utility I'm working on ATM - SimpleBackupAndRestore - with @greengeek is currently up to v4, after several modifications (and 'fixes' to handle directory names with spaces!) This one doesn't even pretend to handle multiple time- and date-stamped archives; rather, it lives up to its name - "Simple" - and just provides a single, 'current' backup of either a frugal install, a save-file /folder OR archives of personal data.

He found a very useful link to an old thread over at StackOverflow which provided plenty of insight into where I was going wrong. Together with re-acquainting myself with the way that "cp" actually works (I was making a stupid, basic mistake!), I think we've "cracked it" at long last.

Ian's trialling it out for a few days, and will report back on any issues, though I believe we've now sorted those out. His HDD's making ominous noises, so he wants to back-up a load of stuff before getting a new SSD for his Toshie.

Once he's happy it's doing everything we wanted from it, I shall publish it. I don't mind collaboration where the other participant(s) are equally interested in what's going on with a 'project - however small - AND help by making useful suggestions/contributions of their own. It's quite rewarding!

Mike.

@bigpup

You've found a genuine mystery. Haven't been testing in BW64 10.0.9, my mistake.

Two things:
1. An un-compressed folder backup doesn't need to be restored since it is
listed in the boot choice menu by default. May need to detect that and message
user if they select one by mistake.

2. Bigger issue, the program code uses this to find the backups:

ls *.BKP*

This normally returns only the files/directories containing ".BKP".

That doesn't work in BW64. In the image below, the first "ls" command shows all contents
of the directory. Next, you see that "ls *.BKP*" returns only "upper" and "work", so the program will
fail. Have no idea why this happens, perhaps @dimkr or one of our other experts can explain it.

Thanks
wizard