Puppy 4.2

[Pizzasgood]

Woah, cool! So that's what hard links are good for.

That technique wouldn't work for backing up a save file unless you pulled the contents out of it, since it's just one big file. The problem then is that it would need a linux partition to store them on, so people who run it on Windows-only machines would be out of luck. A way around that could be to set up another filesystem image for just backups: pup_back.2fs. Since you're not running from that file, it could be resized without having to reboot first like with the pup_save.2fs file. It would just need to be unmounted if it isn't already. So it could be kept close to the size of the actual data inside to avoid wasting harddrive space.

Using the .2fs extension would still let you just click it to mount. Though maybe it would be a good idea to add a new extension .ROfs, and make the run-action mount .ROfs files as read-only. That way if somebody clicks it to mount it, they won't modify anything.


That method might be overkill though. Fewer opportunities for errors with just copying the pup_save.2fs file itself, though it's more wasteful space-wise. Maybe use something like diff or xdelta to only store the differences (the distinction here is that I'm referring to the differences between just two big files, as opposed to an entire copy of every small file that has changed).

[WhoDo]

...see HERE for mirrors and details.

Enjoy!

[PaulBx1]

That technique wouldn't work for backing up a save file unless you pulled the contents out of it, since it's just one big file.

Um, it's my impression that rsync works with pieces of files, rather than whole files. From the rsync site: "It does this by sending just the differences in the files across the link..." So it should work just fine with pupsaves.

I do wonder a bit about encrypted pupsaves. If you change one character in the cleartext state, IIRC you change a block (of some unknown-to-me size) within the encrypted file, but not the entire file. So I think it should work with encrypted pupsaves too, but not as quickly as with unencrypted ones.

I re-read that link and now think I have a handle on what is going on here. Still seems like magic though!

In rc.shutdown, wouldn't this be done just before the "busybox umount -ar > /dev/null 2>&1" at the end? Something like this:

Code: Select all

umount /initrd/pup_rw
sync
rm -rf $PUPSAVEBACKUPDIR/pupbackup.3
mv $PUPSAVEBACKUPDIR/pupbackup.2  $PUPSAVEBACKUPDIR/pupbackup.3
mv $PUPSAVEBACKUPDIR/pupbackup.1  $PUPSAVEBACKUPDIR/pupbackup.2
cp -al $PUPSAVEBACKUPDIR/pupbackup.0  $PUPSAVEBACKUPDIR/pupbackup.1
rsync -a --delete --checksum $PUPSAVE/   $PUPSAVEBACKUPDIR/pupbackup.0/
busybox umount -ar > /dev/null 2>&1

Well, I guess that wouldn't work if 2 different pupsaves were being used on different boots? At least you want to keep the corresponding backup directories distinct.

[Pizzasgood]

I didn't mean there'd be a problem with rsync. I mean using hardlinks wouldn't work, because that technique only prevents you from having multiple copies of identical files - instead you have multiple hardlinks to the same file. When a file changes, the next backup will include a real copy of that file rather than the hardlink. So if you only have one file, every time it changes it will be a complete copy, and you don't save any space.

Looking at the code you posted, it looks like you're backing up the whole subdirectory that Puppy was (theoretically) installed into. In that case, using the hardlinks would save space by preventing multiple copies of vmlinuz, initrd.gz, and pup_xxx.sfs.

Also, if you do use the hardlink method, I don't believe that rsync would give you a speed increase for the part when it copies in a new file over an old one. Normally it would, due to the differences deal, but if the destination file is a hardlink, I believe it would have to copy all the data. Reasoning: The hardlinked file's data only exists in one single place. The two names are just different names to the same file. For it to make the two hardlinks into separate files, the data needs to exist in two separate places. It can't simply drop in the changed data and leave the unchanged parts of the file as links to the original, since links must be done on entire files. So it has to either copy in the entire file rather than the differences, or it must copy the unchanged parts from the old file. Either way it has to do the same amount of writing to the disk as if it had copied the whole thing.

[vtpup]

Yes, for a complete copy of the personal save file that method in the article wouldn't make sense. I wasn't thinking properly about that.

But there might be something useful in it for the case where the frugal was mounted and you were periodically backing up to another mounted version on say an hourly basis, while doing development work. Then you would only lose an hour's worth if you crashed and burned, and the saves would be to individual files and would be rapid and small (hopefully) since only the diffs would be infolved.

Might also be nice to be able to do it with a key combination on demand as well. Kinda like <ctrl> <s> does in some programs, except in this case it backs up the whole OS state!

It would then relieve you of the need to periodically back out of what you are doing and close, reboot another puppy or pfix=ram, save the personal file, close down again and reboot to the original development state. I doubt anybody does that on an hourly basis manually while developing something. Just too painful.

The incremental backups certainly would make sense for a full Puppy HD install. In fact that would make it a LOT tougher system.

I realize though that while running, the HD is in flux, so maybe it's just not possible to do a backup then. Unless you could temporarily halt file changes.

Failing that, and to return to Paul's original request, what would be really helpful to frugalites would be a choice to shutdown (or reboot) with backup of the personal save file included in the shutdown process.

This could be a choice on the main Menu shutdown menu.

[PaulBx1]

Well, it looks like I didn't understand it after all. Now it makes sense, that you say it refers to multiple files and not just one.

Anyway, this multiple backup was a side issue. The main thing is having at least ONE backup, generated from the menu selection at shutdown as you say. If I want more copies I can just do it myself in rc.local I guess.

[Max Headroom]

@vtpup - using Puppy's layered file system it is easy to do both by having barebones + a buildback sfs ...using my example before, just have a symlink to standard.sfs in the /pupXXX directory

I should have a demo build around the new year thanks to some help from pizzasgood with a bash script on this thread
http://www.murga-linux.com/puppy/viewtopic.php?t=36886

The boot menus will be derived from Fancy and Retro Pup - highly modified to include only one vmlinuz, init and "zdrv"(actually an sfs of all files shared by all of the puplets - to save space) I plan to try and include as many smaller puplets as possible + extra sfs modules to top off the iso (basically I am targeting smaller puplets that did a lot of work getting additional window managers & UI all set up hopefully with a good range of browsers and core apps - the rest can be pets & sfs modules until if/when I decide to do a DVD)

Looking Forward 2 This Mate, in Fact I was intending 2 Do Sumthing Simila' if Not as Sophisticated. Bring it on!