Release Upcoming Application : BGS (Backup Game Saves)


ekianjo

Hardcore Member
Joined
May 7, 2012
Messages
8,261
Location
神戸市、日本 (Japan)
Just to let you know, I am currently developing a small application that will save automatically your save game files as well as save states (mostly targeted at different emulators) when launched, and compress the files together, and save them on both SD Card slots (if available) for data redundancy. 

Basically the reason to create this application is because I am worried that one day one of my SD Cards may get corrupt and I end up losing dozens of hours passed on my emulator games. Since it's not really practical to save such files (unless you backup your whole SD card all the time), I wanted an application to focus only on such files. 

I will support all major emulators for the first release. 

I am also thinking to include a "restore" function later on as well. 

No screenshots so far, but you can expect to hear more about this and see it in action in a couple of weeks or so. 

Let me know if you have any feedback so far, or questions!
 
Awesome idea! I'm always worried about losing game saves and this would be a handy feature! 
 
That really sounds like a great idea. Is this planned as a pnd that the user has to start in order to initiate the process, or as a deamon ?

Two thoughts I have on this (don't know wether this is of interest to you, or you even considered them already):

  • What about bringing in flexible support via configuration files:
    A config file would include either the appdata path or the pnd id as an identifier and the type of files that need to be backed up (either complete/absolute filenames or a group of files determined by a wildcard character and a file extension).
  • Supporting other targets other than SD-Card: USB-Sticks or maybe an smb/cifs share (if it is possible to mount those kind of shares on the Pandora)
 
Last edited by a moderator:
That really sounds like a great idea. Is this planned as a pnd that the user has to start in order to initiate the process, or as a deamon ?
This will be a PND. But I will probably add an option to make it start automatically at some point, with daily backup function or something like that.

What about bringing in flexible support via configuration files:A config file would include either the appdata path or the pnd id as an identifier and the type of files that need to be backed up (either complete/absolute filenames or a group of files determined by a wildcard character and a file extension).
This is exactly what the program does internally. I don't think it would be too much of a problem to add support for config files, but ideally I want to keep this in the software so that every Pandora owner can benefit from it. So, in other words: source code will be open and you are welcome to include more support.

Supporting other targets other than SD-Card: USB-Sticks or maybe an smb/cifs share (if it is possible to mount those kind of shares on the Pandora)
SD Cards will be supported out of the box, as long as they are already mounted when the program is started. For other shared drives, this may be possible but not at launch. 
 
What about bringing in flexible support via configuration files:A config file would include either the appdata path or the pnd id as an identifier and the type of files that need to be backed up (either complete/absolute filenames or a group of files determined by a wildcard character and a file extension).
This is exactly what the program does internally. I don't think it would be too much of a problem to add support for config files, but ideally I want to keep this in the software so that every Pandora owner can benefit from it. So, in other words: source code will be open and you are welcome to include more support.
But by using config files also every Pandora could benefit from it - just include the ones that you are already prepared in the pnd. This way also every Pandora could extend compatibilty, not only those that are willing to/able to/not afraid of compiling the source code.
 
But by using config files also every Pandora could benefit from it - just include the ones that you are already prepared in the pnd. This way also every Pandora could extend compatibilty, not only those that are willing to/able to/not afraid of compiling the source code.
Let me rephrase this / explain more. 

There's no need for anyone to compile the source code. I will simply release a new PND once there are config updates so everyone gets them from the repo, instead of sharing text files on the boards or elsewhere. The repo is precisely made for sharing updates of applications and I intend to use it for that purpose. And anyone will be able to contribute to the config files on github.

Another reason why I want control over the config files is that I want to test the changes made before releasing a new version. There may be bugs, there may be things that do not work as expected, and I may have to change other parts of the code depending on the configs.

SO the process, for anyone who want to add more features to the config files:

- use github to edit the config files

- I will test the modifications and see if they work.

- I will integrate the config to the main source once tested,

- I will compile and release the new PND to the repo

That's QA control :)
 
Sounds like you could use rsync as your copy engine, it can do incremental copies (only files that changed) so you don't have to redo full backup each time user runs the tool.
 
That sounds really great.

I am also thinking to include a "restore" function later on as well.
What's the use of a backup tool if the you can't restore the data?

Can it be done manually (copy-paste)?
 
BGS would be a better name for a firewall...


But that's something only germans might think is funny. ;)
 
the funny thing is: i actually had to google "bgs" to get that...  :blink:
 
That sounds really great.

I am also thinking to include a "restore" function later on as well.
What's the use of a backup tool if the you can't restore the data?

Can it be done manually (copy-paste)?
Yes, you could restore it manually! I will need more time to make it automatic.

BGS would be a better name for a firewall...


But that's something only germans might think is funny. ;)
Haha, nice, did not know that reference actually!
 
For a lot of cases I would have thought backing up the entire appdata sub-directory (for said PND) would be the correct thing to do. Based on this I wonder if your application might find benefit in automatically backing up any appdata sub-directory which is less than X bytes in total size (where X is something coming from the config file, set to something you feel sensible, for example 128 KiB). This could be an option which can be turned on/off. I believe with this option you might catch a lot of applications at once, and not require explicit cases for hundreds of PNDs.

EDIT: And the idea of being able to back things up like you suggest is a good one, something just about everything would probably appreciate.
 
Last edited by a moderator:
For a lot of cases I would have thought backing up the entire appdata sub-directory (for said PND) would be the correct thing to do. Based on this I wonder if your application might find benefit in automatically backing up any appdata sub-directory which is less than X bytes in total size (where X is something coming from the config file, set to something you feel sensible, for example 128 KiB). This could be an option which can be turned on/off. I believe with this option you might catch a lot of applications at once, and not require explicit cases for hundreds of PNDs.


EDIT: And the idea of being able to back things up like you suggest is a good one, something just about everything would probably appreciate.
Not a good idea to backup all appdata for dsaid pnd. Some emulators ask for the roms to be in the appdata folde and this can be very big in the end.

Possible owncloud support/torrentsync support? :)


I like this idea! :)
Everything is possible in theory but i dont plan to spend 6 months on this :)


I have other apps in the works, too.
 
Back
Top