> I always find the simplest rule should be based on how much information you can
> afford to lose. For example on most systems it's roughly one day, so you want to
> schedule a backup each day, based on the time of the lowest activity level. In most
> cases the lowest activity is the middle of the night. You can do a backup with the
> database live and running.

I second that - and I run a sweep of the database at the
same time, so that it is not slowing things down during the
day. If they do a major amount of editing, then there is a
manual backup to save those changes, but I don't believe the
customers bother using it now - see comment below.

> As for a restore, I would do a restore to an alternate file at least once after making
> changes to the database structure, perferably every couple of weeks or so. This is
> to make sure the backup and restore mechanism are working properly.
>
> Every couple of months or so, schedule down time, this is a block of six - twelve
> hours or so, when you do system "maintenance", you put the database into
> "shutdown mode", do a backup and restore of the production database (use a
> different file, so if it doesn't restore, you still have the original), once it's done, you
> reboot the server, and then make it available again. This is the time you can also
> apply patches and updates to the system, and make sure they actually are used.

When your customer is running trains 24 hours a day, finding
that period of time is not possible. We only need 10-15
minutes to backup/restore clean, and we have not had to use
the daily backup for 18 months so something is working fine.
We still get a problem on one site, but it is pure windows
netwoking. Ok and restart - everthing is fine as the
database side is never affected.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services