Harut Posted July 26, 2004 Report Share Posted July 26, 2004 (edited) There is going to be ms access database with a vb program written as an interface. the database contains very crucial information and cannot under any, and i mean it any, circumstanses get corrupted, damaged, crashed.... absolutely no data must be lost. thus, i guess, we need a back up system. any general (specific?) tips and suggestions you might offer for backing up such system (access)? thanks Edited July 26, 2004 by Harut Quote Link to comment Share on other sites More sharing options...
Azat Posted July 26, 2004 Report Share Posted July 26, 2004 Harut, since it is a MS Access database you can only backup the entire file unless you go and write custom queries to export data out. What I would do is setup 7 jobs. One for each day of the week. The jobs should just copy that Access MDB file to another server. Each with a different name. That way if you get the file corrupted you do not accidentally copy over the good backup and ruin both. As an alternative you can buy a small backup package that will just keep X number of days of backups. I also highly recommend backing up the application(VB) and the data to a CD at least once a week and keeping it offsite. In general you also should do a real back up of your server at least once a week. just few random thoughts... Quote Link to comment Share on other sites More sharing options...
Sip Posted July 26, 2004 Report Share Posted July 26, 2004 (edited) "absolutely no data must be lost" ... you have said a mouth full. You can't accomplish that by backing up. A "back up" will only get you back to the most recent valid backup so you can't guarranty no data will be lost. One way to do this, is to have 2 identical databases. The VB "front end" will update both databases on each request. This way, if one file gets corrupted, the other will still be valid. Note that with 2, you may not know which one is corrupt and which one is valid. So you can use 3 databases and any 2 that match will determine the most likely "valid" case. Things to keep in mind: 0) Clearly you want the databases separate (even though they are identical) ... so separate access files. 1) It's preferable to have the files on separate PCs to minimize chances of loss, or at least on separate hard disks (or network mounts as the case may be) 2) The VB interface should be bug free. Otherwise, it'll corrupt both databases simultanously 3) You can extend this to k concurrent databases (mirrors?) Of course on TOP of this, you want to do your backups. Depending on the size of the database, you can do it as often as every second down to once a year using the method Azat has suggested. Another thing you can do in additional to all this is, as Azat suggested, to have a background task that exports the data out of the database into some sort of "data file" ... like you can come up with your own visual basic routine to output the data into some ASCII file. This way, even if the database and the backups get corrupted, you will have the data in your own format that you can use to recreate and repopulate the database. A lot of this is overkill but some things demand nothing less Edited July 26, 2004 by Seapahn Quote Link to comment Share on other sites More sharing options...
Sip Posted July 26, 2004 Report Share Posted July 26, 2004 Oh and you can run a RAID system on the PC to eliminate (or really reduce) the chances of disk errors ... or at least such that you can recover if a hard disk crashes. Quote Link to comment Share on other sites More sharing options...
vava Posted July 26, 2004 Report Share Posted July 26, 2004 (edited) Raid drives are essential for peace of mind. BUT the thing that Sip suggested that is ULTRA important for me (especially when you use a phrase like 'absolutely no data must be lost...') is to have your multiple db's on separate servers , preferably in separate locations. Once you've established your backup routines - TEST THEM! Nothing is worse than getting a corrupted DB, falling onto your backups, only to find that the files are not usable due to X reason Edited July 26, 2004 by vava Quote Link to comment Share on other sites More sharing options...
vava Posted July 26, 2004 Report Share Posted July 26, 2004 (edited) Oh, and please disregard Sip when he talks of overkill. No such thing as too much protection. Once the dominos start falling.... Example: DB driven E-commerce web with a MySQL database. Linux server running 2 HDs in RAID - with 2 DBs (one mirror) on the same machine. Cron job to copy the DB to the dev server (in the same cabinet) once a day. Cron job using RSync to transfer the DB to a remote server location every 4 hours. The remote server backups the DB onto a Exabyte Tape Backup drive, with a full backup one weekly, and incemental backups daily.Media in the tape drive is on a weekly rotating schedule with enough tapes for 6 weeks. At any given time, there are 4 'relatively' updated copies of the DB in separate locations (main server, dev server, remote server, last set of tapes) You'd think it was bullet proof. Short answer, NO! Disasters happen. Lost 1 week of data - and 3 days downtime, + labour cost for rebuild. Edited July 26, 2004 by vava Quote Link to comment Share on other sites More sharing options...
Sasun Posted July 26, 2004 Report Share Posted July 26, 2004 As someone who has sufferred from data loss many times, backup is absolutely necessary. My website gets hacked almost every other day by some Arabs (or Arab impostors). After loosing a lot of data I am a good boy now and make frequent backups, as soon as they hack I restore from the backup. As a result it seems like they are quite pissed that I fix quickly and are getting tired of hacking and have left me alone last few days. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.