Database Backup

[tanger32au]

Hi all.
When creating a database program, what do you do regarding backup? At the moment I am creating a second file with the date and keeping these, does anybody have a "better" way of managing this?

Paul

[Rod]

A backup can be tricky. Taking a copy of the database at the end of the day is the easy option. But the restore then becomes problematic because you have the previous days edits to consider. You either need to redo all the edits or keep a backup of the previous days transactions. Then the restore becomes copy the backup and rerun the transactions.

You also need to consider when you become aware of the problem. It may have happened days ago. That brings you to checks and balances. Checks and balances daily or hour by hour can help determine you have a problem.

Then when you have noted a problem what to do about ongoing edits, allow them or cease activity till it is fixed.

All comes down to risk and how much responsibility the programmer takes. For example the humans can be given the responsibility of re entering edits. It need not be the programmers responsibility.

For better advice outline the size and complexity of your database, what transactions run against it and how it is checked for integrity.

[tanger32au]

Thanks.

I am using the "simple database framework" for a custom radio database. So far it is working fine but my concern is around lost records or the file getting corrupted. I have a solid backup system for myself but I can't control what other people do, that is why I want to have this "built in" as much as possible. Would keeping the last X entries / changes in a log file be a good idea?

[Rod]

For that kind of application distributed to users you have much less control. You could host backup files on a server but that is probably a step too far.

One thing to consider is printed backup. An almanac, perhaps a monthly print that provides a record of their months contacts. That way if the main data set is corrupted they may feel less of a loss. Look at printform.bas, the almanac can be quite fancy.

Before you backup to a local file you should run a little check routine. Check the file length matches the record numbers, check a known record matches its last details, check the first entry and the last entry. Then copy to a yyyymmddname.bak file. If possible in a different directory to the working directory, (They could potentially delete the working directory) but it depends how smart your installer is.

The restore routine (program) should involve erasing the faulty file, replacing it with the backup and asking for the days contacts to be reentered.

Offer to print a daily contacts sheet that they might fill in during the session. If they don't fill it in it's their responsibility.

Just my thoughts, well done for thinking about it, most folks just cross their fingers!

[Rod]

Keeping the last entries is great for automated recovery but it adds lots of programming code and responsibility. Probably not appropriate here.

[tanger32au]

Mar 30, 2021 9:52:50 GMT Rod said:

Keeping the last entries is great for automated recovery but it adds lots of programming code and responsibility. Probably not appropriate here.

Thanks for the replies, I will have a look at these suggestions.

[tanger32au]

I have now added some extra code to log all data as entered / changed to a seperate file for DR purposes. This file will grow as data is changed and can be used to import any lost data.