backend backup
- Thread starter razaqad
- Start date
ghudson
Registered User.
- Local time
- Today, 08:42
- Joined
- Jun 8, 2002
- Messages
- 6,193
Best practice to have everybody out while you back it up. You can back the db up while it is still open by another user. Search around for I have code that will allow you to zip up and copy the db file even while it is still open.
- Local time
- Today, 07:42
- Joined
- Feb 28, 2001
- Messages
- 30,567
razaqad, this question comes up in more systems than just Access. At my site, my main machine is running an older version of ORACLE. We still have to take special actions regarding when and how we back up the db files.
You see, the issue here is that the database isn't on the disk. ("What?" you say, "what is this bloody MDB file good for, then?" )
The real database is the set of pointers and cached records in each user's workspace - which resides on each user's local machine. The database file on the shared file server disk is just a shared file. It contains NOTHING that hasn't been written from a workstation. It contains NOTHING that has not yet been committed. It is the running sum of all transactions only up to the point at which you backed up the file. BUT...
You have no idea of what transactions were running inside that database. You have no idea of whether the re-indexing operation is complete. You don't know if a long string of buffers was being written back when you did whatever you were doing to make the copy. You don't know if someone was rebuilding a table and was only half-way at the time. You don't know if an import was complete. All of that because you can only "see" two machines. Your own and the shared file server where the MDB resides. Everything else is on another machine somewhere else and you don't have a reasonable way to see what they were doing. That's a Windows design feature, not an Access flaw, either. Good security says you CAN'T see what was going on outside your own system.
If you attempt to run a backup on an open database (note I did not exclude ORACLE here), you have no assurance of the quality of that dataset unless you know who isn't in it. Namely, everybody isn't in it. Or nobody IS in it. That is the only way to be sure that the tables are fully updated with all transactions that are supposed to be there.
Even though I'm on a military computer that serves a world-wide audience with round-the-clock access, I have to set aside some time every day so I can do some backup and storage area network operations with my databases closed. I won't tell you how painful it was to get the military to agree to that request, even for a lousy little personnel pay system. But it is the only way to assure that when we attempt to restart our operation from a backup copy, we can do so.
In October of 2002, Hurricane Lili forced us to attempt a restart at our remote site. Because at that time we didn't realize how important it was to toss out users for a daily backup cycle, we were unable to come up. The issue was that the data image was a halfway-updated image. It was self-inconsistent. We were lucky that Lili veered away from our primary site and didn't crash anything of ours.
By August of 2005, we had a daily down time for our special operations and were able to come up at our remote site after Katrina took out New Orleans. I cannot stress how important it is to take whatever steps you need to ASSURE (not just guess and hope) that you have usable copies of your data that can be re-activated from a backup/replication copy.
I happened to have a system for which backup and storage area network data replication issues had been solved. Well over 40% of our projects had not yet addressed the problem at all, another 20% had given it lip service only. They were down for times ranging from two weeks to two months. All because they ASSUMED things were OK.
So, razaqad, if this database is really important to your company, my advice to you to is to strongly emphasize to your management team the need to ASSURE proper copies exist by setting aside a backup time. Don't ASSUME. ASSURE instead. You'll sleep better at night knowing you can ride through a disaster. (Not to mention that if the pungent brown detritus ever DOES hit the rotating air destratification device, you'll come out smelling like a rose and looking like a genius.)
You see, the issue here is that the database isn't on the disk. ("What?" you say, "what is this bloody MDB file good for, then?" )
The real database is the set of pointers and cached records in each user's workspace - which resides on each user's local machine. The database file on the shared file server disk is just a shared file. It contains NOTHING that hasn't been written from a workstation. It contains NOTHING that has not yet been committed. It is the running sum of all transactions only up to the point at which you backed up the file. BUT...
You have no idea of what transactions were running inside that database. You have no idea of whether the re-indexing operation is complete. You don't know if a long string of buffers was being written back when you did whatever you were doing to make the copy. You don't know if someone was rebuilding a table and was only half-way at the time. You don't know if an import was complete. All of that because you can only "see" two machines. Your own and the shared file server where the MDB resides. Everything else is on another machine somewhere else and you don't have a reasonable way to see what they were doing. That's a Windows design feature, not an Access flaw, either. Good security says you CAN'T see what was going on outside your own system.
If you attempt to run a backup on an open database (note I did not exclude ORACLE here), you have no assurance of the quality of that dataset unless you know who isn't in it. Namely, everybody isn't in it. Or nobody IS in it. That is the only way to be sure that the tables are fully updated with all transactions that are supposed to be there.
Even though I'm on a military computer that serves a world-wide audience with round-the-clock access, I have to set aside some time every day so I can do some backup and storage area network operations with my databases closed. I won't tell you how painful it was to get the military to agree to that request, even for a lousy little personnel pay system. But it is the only way to assure that when we attempt to restart our operation from a backup copy, we can do so.
In October of 2002, Hurricane Lili forced us to attempt a restart at our remote site. Because at that time we didn't realize how important it was to toss out users for a daily backup cycle, we were unable to come up. The issue was that the data image was a halfway-updated image. It was self-inconsistent. We were lucky that Lili veered away from our primary site and didn't crash anything of ours.
By August of 2005, we had a daily down time for our special operations and were able to come up at our remote site after Katrina took out New Orleans. I cannot stress how important it is to take whatever steps you need to ASSURE (not just guess and hope) that you have usable copies of your data that can be re-activated from a backup/replication copy.
I happened to have a system for which backup and storage area network data replication issues had been solved. Well over 40% of our projects had not yet addressed the problem at all, another 20% had given it lip service only. They were down for times ranging from two weeks to two months. All because they ASSUMED things were OK.
So, razaqad, if this database is really important to your company, my advice to you to is to strongly emphasize to your management team the need to ASSURE proper copies exist by setting aside a backup time. Don't ASSUME. ASSURE instead. You'll sleep better at night knowing you can ride through a disaster. (Not to mention that if the pungent brown detritus ever DOES hit the rotating air destratification device, you'll come out smelling like a rose and looking like a genius.)
Keith Nichols
Registered User.
- Local time
- Today, 15:42
- Joined
- Jan 27, 2006
- Messages
- 431
Automaticly back up database?
Hi guys,
Another intersting discussion.
Databases aren't my main bread and butter (thankfully for all concerned!), and I'm not always available or consistent enough to do a daily back up. Is there anyway to do an automated back up?
My db is used in one location, and has a Front End shutdown feature to close users out after 5 minutes of inactivity. Even if a user does not log out, it is not in use outside of local office hours.
Can a databse be configured to start at a predetermined time (say midnight) and run a routine to back itself up, delete an old backup, fill a control on the switchboard to show date and time of last backup, then close. I'm thinking a daily backup with the latest back up deleting the back up of 1 week before. So you always have a week's worth of data
The db has a shut down all users feature which could be worked into the routine.
Regards,
Keith.
Hi guys,
Another intersting discussion.
Databases aren't my main bread and butter (thankfully for all concerned!), and I'm not always available or consistent enough to do a daily back up. Is there anyway to do an automated back up?
My db is used in one location, and has a Front End shutdown feature to close users out after 5 minutes of inactivity. Even if a user does not log out, it is not in use outside of local office hours.
Can a databse be configured to start at a predetermined time (say midnight) and run a routine to back itself up, delete an old backup, fill a control on the switchboard to show date and time of last backup, then close. I'm thinking a daily backup with the latest back up deleting the back up of 1 week before. So you always have a week's worth of data
The db has a shut down all users feature which could be worked into the routine.
Regards,
Keith.
Keith Nichols
Registered User.
- Local time
- Today, 15:42
- Joined
- Jan 27, 2006
- Messages
- 431
ghudson said:
Hi GHudson,
Our corporate policy is for all users to switch off their pcs when they leave the office. I would have to contact the IT department to see if there is some scheduling facility within the network. I guess there must be servers running 24/7 that could accomodate this.
I think that you are not a fan of macros. Would the best way to run back-up code be with a command line switch to a macro? This would prevent the procedure trying to run at any other time it was opened. Is this a sensible approach?
From Command Line Help:
*****
/x macro Starts Microsoft Access and runs the specified macro.
Notes
To run a Visual Basic for Applications procedure when you open a database, use the RunCode action in the AutoExec macro or in the macro that you run by using the command-line option /x.
*****
As I am inherently lazy and fairly new to all this, I'm wondering if you know of any sample databases with this sort of functionality that I could pick apart?
Regards,
I have another question related to this thread.
What about FE open but it is not accessing any data from BE. I mean the FE is open but no object is open. In my application the user navigates through toolbars and menubars. There is no swithboard etc.
So if the user hase no objects open in the FE, would it be safe to backup the BE. E.g if I close all the objects (reports forms etc) and then halt the users FE by opening up a modal popup form without any exit button and close it after the backup is completed. Would it be safe to do a backup like this.
I would setup an ini file on server with a key set to "locked' and there would be a hidden form on user's FE with timer querying the ini file. and when it gets the status to "locked" it would warn the user and then lock up the system a i have said above.
What about FE open but it is not accessing any data from BE. I mean the FE is open but no object is open. In my application the user navigates through toolbars and menubars. There is no swithboard etc.
So if the user hase no objects open in the FE, would it be safe to backup the BE. E.g if I close all the objects (reports forms etc) and then halt the users FE by opening up a modal popup form without any exit button and close it after the backup is completed. Would it be safe to do a backup like this.
I would setup an ini file on server with a key set to "locked' and there would be a hidden form on user's FE with timer querying the ini file. and when it gets the status to "locked" it would warn the user and then lock up the system a i have said above.
ghudson
Registered User.
- Local time
- Today, 08:42
- Joined
- Jun 8, 2002
- Messages
- 6,193
What if they have a data form open? Then they must have a record source open if they are view/adding/editing data. I recommend that you kick the users out of the db before you back it up. Do what you want but you might be surprised one day when you need to restore the db from a backup and the data for one or more records is corrupt because the users had a record source open while you were coping the db.
Similar threads
- Question
