DONATION Backup/Restore Changes

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!

14 thoughts on “DONATION Backup/Restore Changes

  1. Good idea, Dan.
    I like the idea of keeping only the last N backups. This would achieve the objective and not eat up storage. Having N backups is way better than now where we only have one, so I don’t think N would be a problem for anyone.
    As far as Restore is concerned, why not simply list the N backups and ask which one they want to restore. The date interpretation could appear in the dialogue box e.g: The floowing backups are available: DONATION2011-12-07.DB.GBK created on Dec 7, 2011,
    DONATION2011-11-26 DB.GBK created on Nov 26, 2011,
    and ask which one they wish to restore

  2. I agree with Peter Davidson – keep N backups. Having the backup date AND TIME as part of the backup name is what I rely on with Quickbooks and other programs. The TIME would be nice, but a serial number would do as well. I often make several backups on the same day – basically every time I leave any of my accounting-type programs. The Restore needs to give a choice of a list of backups as Peter said.

    I don’t think it’s necessary to find the latest donation date in the backup file – the filename should provide enough information – as that would slow down the restore process considerably if the data file is large.

    A Restore warning other than “are you sure” would be superfluous in my mind.

  3. Thanks for these ideas, Peter and Klaus.

    I’m not too inclined to add the time to the backups, as that’s yet another complication, and makes the filenames rather long. You can always add your own bits to the backup filename if it’s important to you. (And I think the vast majority of users would backup at most once a day, more likely once a week.)

    The extra time taken to open the restore file and check the latest donation date in it would be minimal, maybe a second or two. I think it’s still well worth it. And don’t forget, some people will be restoring backups from before this change is made, that therefore don’t have the date in the filename.

    The selection of the backup file to restore really has to be done with a regular Windows “File Open” dialog box, to allow you to see what files are in your selected folder, and navigate to other drives and folders as required. That dialog box by default shows just filenames on most systems, though you can change it to also show sizes and dates. But the date is in the filename, so hopefully that should be sufficient for selecting the desired one.

  4. I believe that the backups could have a number for every backup you make. I would know if I backup #400, I would erase #399 for instance. The date and time is also important.

  5. Dan.. three comments..

    1. The problem you describe is one of someone mistakenly restoring and not realizing the consequences. This could be corrected by flashing up a more complete and specific warning message.. such as”WARNING.. you are about to restore a data file with a backup that is xx days old. All data between today and xx/xx/xx will be lost. ARE YOU SURE?”

    2. Multiple backups is really a feature enhancement which may or may not solve the above problem, depending on the habits of the user.. if they only back-up every 3 months, they could still have the problem regardless of the naming convention… I don’t see the likelihood reduced. Generating an automatic backup at each exit is the only way I can think of to solve this problem..and this has the downside of not always being what one would want to save as a back-up.

    3. I personally like multiple backups. I favor saving “n” backups where “n” is user selectable. If the file name has a unique name (backup 1, backup2, for instance) and the file attributes are visible when restoring (they already contain a date and time), it would seem we have what we need. I don;t think this makes your other problem automatically go away, however.

    David

  6. Adding the date to the default file name would be helpful. Before (or after) major data entry or changes I add the date to the ‘old’ default name. If/when Dan’s change is implemented, it would be simple for the user to insert a ‘-1, -2’ etc into the file name when multiple backup files are created on the same date.

    I would argue against the “keep most recent N files” and leave pruning un-needed backup files to the individual users – although that could expose one to the risk of accidental deletions of a still-valuable file. My 2 cents.

  7. Dan:
    I vote for the idea of keeping N number of backups and i like the idea of using the date as part of the name. I have on a number of occasions been asked to restore a back up file and have no idea of how old it is without looking for the file details which are hidden on most of the newer computers. The name always shows.
    A more detail warning during the restore process could be beneficial and make people think about what they are doing, the first time. It may caution some everytime.
    My own thoughts are that the ones with the problems could be flipping datasets between computers and forgetting that a restore was done already with a particular data set. This has happened more than once with my clients with Donation and with QB even with its fancy name etc.
    I like your thought of trying to help. Keep up the great work.

    • That’s a really plausible thought, Clyde, that the ones with problems were transferring data between computers. I hadn’t even thought to ask about that!

  8. I have always added the date to the backup filename, so I’m good with that change.

    I would make the “keep N backups” an optional checkbox. I’ve got weekly backups going back nearly three years. I don’t need to keep them all, but I would certainly want to keep the final backup made in each calendar year.

    • One thing is that the “keep N backups”, which I agree should be optional, would only refer to your currently selected backup directory. So if you put your year-end backup in a different directory from the regular ones, it would not be subject to being deleted by the “keep N backups” feature.

      This is both a feature and a programming limitation – the program could not realistically keep track of all of the places you have made backups, and anyways hopefully they would be on an external medium like a USB memory key etc., and it might not be the same key!

    • I actually added in a trick as I was programming this, namely that the backups to be deleted in response to the “keep N backups” option are only ones that start with “DONATION”, and end with “.DB.GBK” (or .whatever.GBK, if you have multiple databases).

      That way, if you purposely rename a year-end database, say, to 2011YearEndDONATION.DB.GBK, it will never be deleted by that feature.

      Of course, the documentation will say that. Now all I have to do is get people to read the documentation! 🙂

  9. One other point. If one is emailing backups to a storage email address you already have multiple backups.. Also with date and time via the email.

    David

    • Yes. I suppose another option would be to have an option in the Backup Options window to always email a backup after doing the regular Backup/Restore -> Backup Database menu option (or the equivalent action if it prompts you to backup as you exit the program).

      Unfortunately (in reference to then next blog about cloud backups) not everyone has (or wants to set up) a webmail account, that they could email backups to.

  10. Pingback: DONATION version 3.40 w/ Backup Changes « Software4Nonprofits Blog

Comments are closed.