By Chris Lee

Many years ago someone asked me to set up a computer system. It was to do some spreadsheet work on a big mainframe (I did say it was many years ago!). I did as requested and left the guy to work away, in an office, on his own.

Every time I passed the office, I would pop my head in and ask, “How are things going”? Each time I was told “Great”. I would ask if the system was being backed up, to which I was told “Yes, yes”. He was not irritated but he thought I was fussing too much.

Two days later, the guy came into my office and asked, if the machine stopped working was there anything I could do? I asked about the backup copy and he admitted that it hadn't been happening!

Nope. there was nothing I could do. The same will be true today, if you do not back up your system and here I am particularly thinking of TurboCASH, you will loose everything.

There have been studies done that are disturbing. They quote various figures but put simply they all say, the majority of businesses that lose their systems, very quickly cease trading as a result of their loss

Statisitcs on Dataloss

How to Backup in TurboCASH

The Bigger the System, the Bigger the Problem

The more transactions you have, the bigger you have a potential problem when your system stops. There are different strategies that you can use. The first one is, utilise the printer. I often print my accounts every month and these are filed away. This checkpoints my accounts. If I loose my system, I don't have to rebuild the complete system. Instead, I just begin a new system, with opening balances from my last checkpoint. This works but only for small systems. As you get bigger, this becomes less of a viable strategy, you need to be able to rely on the computer system being there, when you need it.

The first thing is to ensure that you have a record of your transactions. This is often termed the Prime Document or Source Document. It is just no good typing the transaction into the computer and expecting it to be there forever. You need to keep a record of this with a Prime Document. Work on the assumption that you are going to loose your system in an hour and you will not go far wrong. For example, it is fine to issue a customer an invoice straight from the computer, perhaps for goods that they are taking but you also need to record the fact. This could just be a book that records the invoice number and the goods that were taken from your store, when and by whom. You could even get a signature, this is a poof of delivery. Think it right through. It's no good having this information kept on the same system that you have just printed your invoice from, it could be the failing system.

The next thing to do is ensure that you are backing up your system on a regular and predefined basis. This should be done at a time that enables you to identify all the transactions that have been created during the period. So, for example, you take a backup every night, just before you go home. It means that if your system fails at 11.15 in the morning, then, you have last evenings backup to restore and all the transactions up until the failure.

What we have is a known checkpoint and a known list of transactions since that point in time.

A strategy sometime used by small traders, is to backup often but not note exactly when or what transactions apply. Well, this is why you keep a copy of those receipts you give to your customer. They are the Primary Documents of your accounting system and represent your transactions. This is not so much a problem if you have already been paid for the work but if you extend credit, this is what you are owed and by whom. So if your system fails, you can rebuild your system from the last backup with these transactions. Think the problem right through. If it is not vital that you get every transaction but that you get the majority of them, then fine, you know that if you loose your system, there may be errors and you're just going to live with them. If, on the other hand, you need to capture each transaction then you need to ensure that you have good cut-offs and timings of your system backups.

As a discipline, it is wise to do your backup at a specific time during the cycle of your day or week. However, lets say you don't update your computer system until fill a shoebox with receipts. That's fine. Just process everything into the system, clean your shoebox, then do a backup. What this means is that you are doing a checkpoint at a known point. All you must do, is mark these transactions as processed and what batch they are (file the whole shoebox and mark it with a processed date). This means that, if you loose your system, you can restore your backup with the last known, good backup, and reload the last batch or batches. Again, this is knowing all that went before and after the last backup.

Put simply, you know when the last backup was made and what transactions are included in this checkpoint of your accounting system. You know which transactions you need to apply to restore your system to the point were if failed.

Remember, it is possible that the problem that you find, may cause you to go back to more than your last backup, it could be a number of generations before that. This makes knowing what makes up each of your checkpoints, even more important.

Finally, there is the big one! Here we have transactions going in all day long and we cannot have failure. Failure is just not an option!

This requires that we take an even more disciplined approach to the problem. We know that one day, the system will break. What we don't know is when and what transactions will have been processed. At each stage we will put in place controls that will minimise the disruption to our business. Here again, there is a dependency on the transactions, we need to be able to reconstruct the failed data input.

If transactions can be reconstructed from documents then a checkpoint every day, hour or minute can be a solution. However, this will need people to come off the machine at a specific time. Whilst the database will handle the mechanical process of not stopping people work, it is the timing of the transactions that causes the interruption of work. If the loss of a transaction is not important, then there is no need to interrupt the work as the database should handle the backup process in the middle of transactions being put into the system. We recognise that we may loose a number of transactions on a system failure but that the cost of preventing this is not worth our efforts.

If you do not want your systems to fail and you want to put though the computer all your transactions, then you need to take this to the next step which is working through a failure analysis and workout where you points of failure are and minimise them. But, your system will always fail, defend against it happening soon.

Things you need to consider are:

• If everything stops. This means, the computer stops, all your networks stop, the main server stops – everything has gone! This not a theoretical fancy, it has happened. For example, someone comes into your premises and steals all your equipment or a lightening storm fries your machines. You need to ask yourself, what is the effect of this?

• You loose just your PC. The server is still protected. What is the effect?

• You loose your server with all its data. What is the effect?

• You loose the use of your network. A local network to your server or the Internet. What is the effect?

I know that I am being extreme but this is all possible and TurboCASH users are not exempt from the problem.