(old)Puppy Linux Discussion Forum

Posted: **Sat 22 Apr 2017, 00:55**

spiritwild wrote:Good job, the Izop compression was much faster than I was aware of. I'm keeping this one around

Similar compression speed to LZ4 however LZ4 isn't a common busybox compression option. For restores LZ4 is much quicker, it can decompress using multi-cores at speeds approaching ram speeds. Compression isn't as tight however as the likes of gzip.

All-told lzo level 1 is a good choice IMO, more readily available (in busybox) and compressed size (disk IO) versus speed has a nice balance (what is lacks in compression tightness it makes up for (and more) in speed). My preferred choice of kernel (initrd) compression (unless lz4 is available).

Posted: **Sat 22 Apr 2017, 01:15**

rcrsn51 wrote:Excellent. Are you doing "hot" backups from a running Puppy?

All my runs were doing "hot" backup of savefolder on Fatdog.
But my saveinterval is zero so that would also give no problem. Maybe setting saveinterval to zero on savefiles will work too.

Posted: **Sat 22 Apr 2017, 02:58**

@rufwoof: Are you providing a test report on this specific project?

Posted: **Sat 22 Apr 2017, 04:49**

drunkjedi wrote:
rcrsn51 wrote:Excellent. Are you doing "hot" backups from a running Puppy?
All my runs were doing "hot" backup of savefolder on Fatdog.
But my saveinterval is zero so that would also give no problem. Maybe setting saveinterval to zero on savefiles will work too.

Hi drunkjedi and all.

I've been using SFR's PackIT to lzop, lz4, even zip the pupsave of the
Puppy from the Puppy itself for years. I never had a problem.

Just make sure there is no other operation going on in the Puppy when
you do it. And if you have defined save intervals, no expected pupsave
update in the next three minutes.

Also the following should be obvious: the destination archive of this
archiving operation has to be outside the pupsave, in
/mnt/home/"PuppyDir", next to the pupsave file. Do not edit the PackIT
default directory and you'll be fine.

IHTH.

Posted: **Sat 22 Apr 2017, 14:28**

rcrsn51 wrote:You can also use SFB to backup/restore any collection of data. It puts a ".sfb" extension on the image files to distinguish them from other archiving formats.

Thanks a lot, rcrsn51.
I installed the SFB and the lzop pets, and tried it on a 472K folder with two files in it. It made a tax.2017-04-22.sfb file of 374K in about 1 second.

---------

Booted tahr6.0.6 again, this time with pfix=ram
Installed the two pets.
Used SFB to save a 386MB save folder
to a 238MB tahrsave-feb26.2017-04-22.sfb
Took about 10 seconds.

Restored it (to a different partition) in 4 seconds

Posted: **Mon 16 Oct 2017, 23:40**

shameless praise.....

This is still the single greatest backup tool on the whole damn planet.

Edit: out of curiosity, is it possible to add a line to the code that will play a sound when "done" ?

Sometimes I'm not at the pc and a notification would help me out.

I have a soundfile I like and use aplay in scripts, I'm not familiar with GTK though.

Thanks!!

Posted: **Tue 17 Oct 2017, 13:00**

The program is /usr/sbin/SaveFolderBackup. Between lines 17 and 18, insert a line like:

Code: Select all

aplay /path/to/soundfile.wav

Posted: **Thu 09 Nov 2017, 14:55**

Hello! I'm having an issue, I have a big SFB file (~3.5GB) in my flashdrive, and when I want to "restore" it, It just says "done" but it does nothing.
Is there a commandline that I can use to do the same restore action and actually see if there's something wrong?
Thanks.

The issue is with lzop pet you gave, it doesn't install correctly, I ended up compiling from source so no big deal luckily. Thanks

Posted: **Thu 09 Nov 2017, 15:03**

It's using

Code: Select all

lzop -d -c "source file" | tar -x -C "destination folder"

The issue is with lzop pet you gave, it doesn't install correctly,

In which Puppy are you working?

But how were you able to make the backup in the first place if lzop wasn't working?

Posted: **Thu 09 Nov 2017, 15:59**

rcrsn51 wrote:It's using
Code: Select all
lzop -d -c "source file" | tar -x -C "destination folder"
The issue is with lzop pet you gave, it doesn't install correctly,
In which Puppy are you working?

But how were you able to make the backup in the first place if lzop wasn't working?

Well I made the backup on my TahrPupx64 and now I'm on a RAM puppy that's literally clean, so I was able to make the backup on my "save-session" puppy, but not able to restore it on my "RAM session" because of this issue.

Posted: **Thu 09 Nov 2017, 16:02**

There are two lzop PETs - 32bit and 64bit. Are you using the right ones?

Posted: **Thu 09 Nov 2017, 16:18**

rcrsn51 wrote:There are two lzop PETs - 32bit and 64bit. Are you using the right ones?

Oooh DUDEEE I never saw that description!
Hahahaha
Srry!

Posted: **Sat 11 Jan 2020, 09:10**

This is a bump, so this very good program, gets some daylight in the forum.
I hate the way stuff goes deeper and deeper, into the pages of this forum.
A lot of good programs, are lost, when they get 40, 50, 60 70, pages down, into forum sections.

Note:
I suggest you put the download, for the latest version of the 32bit and 64bit, in the first post of this topic.

Posted: **Sat 11 Jan 2020, 13:33**

bigpup wrote:I suggest you put the download, for the latest version of the 32bit and 64bit, in the first post of this topic.

There is only one version of SaveFolderBackup. The 32/64bit refers to the optional lzop packages, as is already stated.

Posted: **Sat 11 Jan 2020, 14:08**

This is the first post in this topic.
Where does it say SaveFolderBackup pet package will work on 32bit or 64bit Puppy versions?

If you are going to post the 32bit version of lzop pet on this first post.
Make it easy to find the 64 bit version, by also putting it in the first post.

You may think putting a note in the comment for the lzop 32bit pet will always be seen by people.
Not!

Peoples minds do not always work that way

rcrsn51 wrote:Update: SaveFolderBackup v1.2 also works with save files. Drag the file into the selection box.

Hint: The best way to use SaveFolderBackup is to backup/restore Puppy X by working from another Puppy Y. Puppy Y could be on a bootable flash drive that also stores the image files.

Doing "hot" backups of save files can lead to big trouble when you try to restore them. But I've had good luck doing it with save folders. YMMV.

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

SaveFolderBackup makes a backup copy of your Puppy save folder by compressing it into a single image file and storing it in another location. You can then restore it if needed. Because the backup image is a file, you can store it anywhere, like on a FAT32 flash drive.

Install the PET and look in the Utility menu.

SaveFolderBackup uses lzop compression. All Puppies have lzop via Busybox, but the "full" version attached below is faster. The PET is built from Debian packages.

You can also use SFB to backup/restore any collection of data. It puts a ".sfb" extension on the image files to distinguish them from other archiving formats.

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

Posted: **Sat 11 Jan 2020, 14:24**

Doing "hot" backups of save files can lead to big trouble when you try to restore them. But I've had good luck doing it with save folders. YMMV.

I wonder if it would not be a problem, as long as the save file or folder, was not being written to, when the backup was being made.
If auto save was setup to not activate.
No other programs running in background.
If it only backs up the already written save and gets nothing from the save ramdisk.

Another save backup program has this help info.

Posted: **Fri 08 May 2020, 17:41**

bigpup wrote:
Doing "hot" backups of save files can lead to big trouble when you try to restore them.
But I've had good luck doing it with save folders. YMMV.

>>> Good Point.
Good that you mention this "caveat" .

"Hot Backup" script on the "Current SaveFILE/SaveFOLDER".
that only works if SnapMergePuppy has finished
is not a "SAFE" "Hot Backup" .

As we recall, from reading the original "SaveFolderBackup v1.2" code.
it calls SnapMergePuppy ('SMP') prior to calling the compression function.
We are guessing that this would probably beat 'SMP' to the punch
... but that is not guaranteed.
'SMP' should be disabled from auto-save.

We only use "saveFOLDER" method ,
and SnapMergePuppy auto-save is disabled.
We wrote our own Save2Flash routine, iconed on desktop,
and purposely disabled auto-save.
We do not use SaveFolderBackup v1.2 ,
instead we wrote our own,
with the goal of being "Simple", "Readable", "Modifiable".
When we wrote "B2T" ..
we did not call for SnapMergePuppy.

IMO, The best method is to use saveFOLDER,
and disable the auto-save,
and do frequent 'HotBackups"
letting a DateTimeSeconds stamp prevent duplications.
"rc.shutdown" still 'asks-to-save', on a 3 second wait.

We used the original "SaveFolderBackup v1.2" for a long time,
but when we changed our systems,
we are not mounted on "/Mnt/Home/"
and the program was cumbersum in the Select-Box
... so we wrote our own which pulls controlling Source and Target info
directly from '/etc/rc.d/PUPSTATE' and automating our standard input.
Early this year we re-wrote it to be "Simple" "Readable" "Modifiable"
We can use it as a "tutorial" script, with good results.

So, that is the method we use with "B2T" in our systems.
[ B2T presented at
http://murga-linux.com/puppy/viewtopic.php?t=118076

In the long run, for any amount of money paid for our projects,
we cannot protect the user from himself.

(old)Puppy Linux Discussion Forum

Save Folder Backup and Restore

Re: Save Folder Backup and Restore

Doesn't restore

Re: Save Folder Backup and Restore