Idea for Tiny Core, a "safebackup" boot option

[ixbrian]

I'm not sure if this has been brought up before (I searched and didn't find anything.)   I was recently using a laptop with Tiny Core on it.   I realized the battery was low, so I decided to shutdown the system and did a backup as part of the shutdown.   As you can probably guess, the battery died mid way through the backup, and I ended up loosing a bunch of files (doh!)

One possible solution would be having a "safebackup" boot code.   This code could simply cause filetool.sh to do a "mv -f mydata.tgz mydata.tgz_backup" and verify the mv was successful before the backup runs.  This way if something went wrong during the backup you could use the "mydata.tgz_backup" file. 

This wouldn't slow down the backup process at all, but would require you to have at least as much free space on your backup device as the size of your backup.   

Brian

[bigpcman]

I'm not sure if this has been brought up before (I searched and didn't find anything.)   I was recently using a laptop with Tiny Core on it.   I realized the battery was low, so I decided to shutdown the system and did a backup as part of the shutdown.   As you can probably guess, the battery died mid way through the backup, and I ended up loosing a bunch of files (doh!)

One possible solution would be having a "safebackup" boot code.   This code could simply cause filetool.sh to do a "mv -f mydata.tgz mydata.tgz_backup" and verify the mv was successful before the backup runs.  This way if something went wrong during the backup you could use the "mydata.tgz_backup" file. 

This wouldn't slow down the backup process at all, but would require you to have at least as much free space on your backup device as the size of your backup.   

Brian

I have had various similar backup corruption problems from time to time. Another idea would be for backup to keep a shadow backup copy, that is save the current backup file before overwriting it. I do this now manually to avoid having to rebuild the backup file when it gets corrupted.

[roberts]

Since what is being proposed is optional via said bootcode, I don't see any issue in its implementation.

[sandras]

good idea, ixbrian!

[roberts]

As I recall, the name of the backup file, mydata.tgz, was selected to support 8.3.
 

[ixbrian]

It looks like all that needs to be added are these 3 lines of code right under the  "if [ $1 == "backup" ] ; then" line in filetool.sh

As discussed, this will simply rename your current mydata.tgz to mydatabk.tgz (which is 8.3 friendly) so that your original mydata.tgz isn't overwritten with the new backup.  You will be left with mydata.tgz which is your current backup and mydatabk.tgz which is the backup before the current one.  If anything fails during your backup you should be able to use mydatabk.tgz to recover to one backup before the current backup.   This does not increase backup time, but does require additional storage space to hold 2 copies of your backup.  

Code: [Select]

 if grep -q "safebackup" /proc/cmdline; then
    mv -f $MOUNTPOINT/"$FULLPATH"/mydata.tgz $MOUNTPOINT/"$FULLPATH"/mydatabk.tgz || (echo "Error: Unable to rename mydata.tgz to mydatabk.tgz"; exit 2)
  fi


[maro]

How about widening the scope just a little bit: In addition to the boot code 'safebackup' why not allow it as a parameter as well. This would then enhance the usage to: filetool.sh {(save)backup|restore}

Unfortunaltely I have not done a (tested) patch for this yet, and it's getting a bit late here. But I'm happy to provide a (tested) proposal by tomorrow.

[roberts]

Guys, thanks but I really don't need patches to something that I originally wrote.
I have already implemented it as both a boot time and run time option.

[curaga]

@ixbrian: exit in a subshell would not do what you intended.