Software4Nonprofits Blog

Hello again DONATION advisors. Thanks to all of you who responded to my post yesterday about proposed backup and restore improvements.

Unfortunately, I thought of something else significant after making that post, which I’d also like to ask you about.

I considered this some time ago, and rejected it in favour of the email backups option I added, but I’m again considering adding an option to backup to “the cloud”, i.e. remote Internet-based storage. It might be on my own web server, or I might use a service like Amazon’s S3 (Simple Storage Service).

The idea would be that as an option, following every regular backup, an encrypted version of your backup would also be sent to the online storage. Obviously this would slow things down, depending on your Internet speed and the size of your database backups, but it would give an additional enormous level of security for your backups.

One big concern would be distinguishing everyone’s backups from everyone else’s. My thought is that the first time you went to use an online backup, a special guaranteed unique ID would be generated for you, and stored in your database. That key would be used to identify your backups online. It would also be transmitted to me (the first time) so that if you somehow lose everything on your computer and all local backups you have made, you can request the key from me, re-enter it into a new copy of the program, and then retrieve that online backup.

There are a couple of options for how the encryption could work. Obviously, it would have to be based on an encryption key.

One option is to just have you provide the key, and also store it in your database for re-use each time you do an online backup (or restore). That’s like how the current email backups work – you provide the key, and if you forget it, you are completely out of luck. It would be the same with this. (I would not suggest that you send me the key – I should have no access to your data.)

Another option would be for me to have a secret way of generating the key from your unique ID, and just use that generated encryption key.

Both methods are succeptible to cracking (though with significant difficulty!). If someone knew your unique ID, they could enter it into a copy of DONATION, and get back your encrypted database. At that point, with the first option (you provided the key), standard methods could be used to guess obviously bad keys (like “password”!) which some percentage of users always use. With the second option (I create the key in a secret way from your unique ID), a very skillful programmer might be able to reverse engineer my program to determine what my secret way was.

And of course, anyone with access to your current database could also get access to your backups stored online. But that doesn’t seem like a big concern, since they already have access to your current database!

There are also privacy concerns in terms of national legislation like the US Patriot Act, which as I understand it gives the US government the right to inspect any data that is stored in the USA, and to demand any required encryption keys from the data’s owner. Apparently there is somewhat similar legislation here in Canada, and Canadian privacy legislation may forbid the storage of such information in the USA. One option with Amazon’s storage is to store the data in their facility in Ireland. I’m guessing that could cause slightly longer transmission times, but might address this issue. Or perhaps users just aren’t that concerned – generally the IRS in the USA or the CRA in Canada would have the right to audit you, including seeing any donation information, anyways!

My web server is in Vancouver, so storing the data there (or in some Canadian cloud storage provider) would at least eliminate the Patriot Act concerns.

Because there is a cost to online data storage (though it’s quite minimal!) I don’t see retaining unlimited numbers of backups from each user online. Perhaps the last 3?

Any thoughts about all of these points, and the general idea? Many thanks!

Hello again DONATION advisors.

I’ve had three or four users relatively recently report missing data within the current year, like “I’m missing all of June and July’s donations, but the ones after that are there”.

Given that there is no feature in DONATION that could possibly mass delete donations like that, the only possibility I can imagine for a situation like that is that at some point in August say, they accidentally (or on purpose, but not understanding what they were doing) restored a database backup from the end of May, didn’t realize that lost them their June and July data, and then just continued data entry from there.

So, I’m working on ideas for some changes to make this less likely.

The first has to do with backups. Currently if your database is the default one, DONATION4.DB, the default backup name you are offered is DONATION4.DB.GBK. You can change that (as long as you leave the ending of “.DB.GBK”), but I’m sure most people don’t.

My idea is to change the default backup filename to be based on the current date, e.g. DONATION2011-12-07.DB.GBK for today’s backup (on December 7, 2011). It could still be changed if desired.

There are two advantages to this. The first is that it will be obvious how old a backup is, that a user is trying to restore (as long as they figure out the YYYY-MM-DD date format, I guess!). The second is that unless the user does something about it, they will have a bunch of backups stored, from all different dates, and each backup will not overwrite the previous one that was stored in the same location.

However, that last point is also a potential disadvantage, as those multiple backups could start filling up whatever storage they were storing it in, e.g. their hard drive or a USB memory key. However, for most users a backup is at most a few megabytes, so it would really take a long time for this to be an issue given the large size of today’s storage.

One option would be to do what some other programs do, and have an option to keep only the last N backups, where they specify the number N (like, last 10 backups). But personally, I think you never know how old a backup you might need. So I’m not sure whether this is a good idea or not.

There could also be an option (on the same window as the one for changing the Backup Reminder Frequency) to go back to the old naming convention, leaving the date part out of the backup filename. But I’m not sure that’s a good idea, as the advantages of the new naming are significant, and the users can always erase the date part from the filename each time they do a backup, if they feel strongly about it.

If I added one or both of the options mentioned above to the Backup/Restore -> Backup Reminder Frequency window, I’d probably rename that menu option to Backup/Restore -> Backup Options.

Now, on to restores. What I’m thinking is that when you go to restore a backup, the program will first open up that backup and find the latest donation date in it. It will compare that to the latest donation date in your current database, and if the backup’s data is older than your current data, it will give a message about it, including stating what each of those two dates is. If the backup data is at least one month older, the message could also say something like “You are about to restore data that is N months older than your current data.” And then of course ask whether they really want to do the restore.

Any thoughts about these changes, and the possible options mentioned above (let them go back to the old backup naming without the date part, and let them specify a maximum number of backups to store in the same location)? As usual, you can Comment on this post to give me your thoughts, or just email a reply. Thank you in advance!