![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: DOORS Database Backups Topic Summary: Created On: 3-Jun-2003 21:23 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I am curious to find out what other DOORS users do or have done regarding backup and recovery procedures for their companies. For example, in our case, our IT support personnel regularly back up the server on which our DOORS database resides. They do full back ups on the weekend and incremental back ups daily. In the event, (God forbid), that we have some kind of catastrophic or malicious destruction of project/folders/modules in our database, we would have be very careful not to restore items which do not need to be restored, lest we over-write the work of some diligent employee who has been toiling away in a project/folder/module not effected by a disaster. Has anybody out there in DOORS-land been faced with situations like this or have you formed policies or best practices that we could learn from in order to make our back up recovery plan be the best it can be for all users?
Thanks! Amy Wesley DOORS DBA Visteon Corporation 17000 Rotunda Drive Dearborn, MI 48430 USA 313-755-5126 ------------------------- Amy Wesley Visteon Corp. Dearborn, MI USA 1-313-755-5126 |
|
![]() |
|
![]() |
|
Amy,
In all versions of DOORS released so far, each DOORS Module resides in a directory structure of the database file system, which can be restored as a directory. As far as I know, restoring this way is not officially supported by Telelogic, although I know of cases where Telelogic support engineers have helped users through the process. I have done it once in DOORS v6, because a server hardware crash caused two Modules that were being edited to be corrupted. Restoring directories in this way may cause issues with Links, depending on the circumstances. I know some people have implemented some batch/timed jobs that Archive Modules and Projects for backup, because restoring Archived Modules and Projects is a supported and documented process. This may be a good supplement to daily backups, but I would never do it in place of daily backup of the file system itself. If the DOORS database is small enough, it is possible for all Projects to be Archived each night. There is also an potential issue with backing up a DOORS database while the DDBS processes are active. The idea is that, even if all users are logged out, the DDBS processes could be writing to the database while the file based backup is in progress. This could, in theory, lead to the backup being corrupt. I have had differing opinions expressed by Telelogic representatives on this subject. When I set up a DOORS server, I usually implement a procedure where the DDBS processes are halted at the start of the backup window, and restarted at the end of the backup window. ------------------------- Michael Sutherland michael@galactic-solutions.com http://galactic-solutions.com |
|
![]() |
|
![]() |
|
Hi there, Mike! Good to hear from you!
Thanks for the response. The only thing is that we are severly constrained in how we do our backups. What I mean is that the people responsible for the actual piece of hardware on which our DOORS database resides is not the same party as the person who is the NT administrator for the server who, in turn, is not the same person who is the actual DOORS DBA (me). What I do know is that our server, like all of our servers, are backed up by tape everyday. That decision is totally out of my hands and the NT administrator's hands. To make things even more complicated, our database is quite large now with many projects and users, making it nearly impossible for me to police it to make sure projects are getting backed up via the application side of DOORS. So, if something catastrophic should happen (i.e., malicious purging of data via DOORS), our only option is to go to our IT people who handle the tape backups and ask them to restore from that. It seems, based on your note, that, if we ever had to do a tape backup, we should not try to restore anything smaller than a project, given the potential issues with links? ------------------------- Amy Wesley Visteon Corp. Dearborn, MI USA 1-313-755-5126 |
|
![]() |
|
![]() |
|
Amy,
I do know there are some potential issues with directory restores and links, but I don't have definite specific scenarios to avoid. As you probably know, Links are stored in the Source Module, but from a user interface perspective they are made to appear to reside in Link Modules. If you are restoring only one Formal Module from a file system directory backup, you would probably be OK. It's when you are dealing with two or more Modules that things may get tricky. Limiting yourself to a Project doesn't avoid the Link issue, because in DOORS v5 and above, Projects can be cross-linked. Basically, since directory restore is unsupported, the implication to Links is undefined. Telelogic once informed me such tinkering with the database structure is a violation of the support agreement, so if anyone ever feels the need, it would be wise to run it by support before doing it. Below is an exact quote: "You have taken steps in violation of your Telelogic Customer Support Services Terms and Conditions. Specifically, you are not authorized to make any changes inside the data directory without a Telelogic Representative on the phone directing you to do so." An alternate strategy would be to restore the entire database in a different location, start up a DDBS process to it, Archive the Module(s) of concern, and then Restore them in the production database. Again, special care needs to be taken with Links. ------------------------- Michael Sutherland michael@galactic-solutions.com http://galactic-solutions.com |
|
![]() |
|
![]() |
|
We have a dual backup system in place here.. At night, our HPUX server automatically brings down both our v5 and v6 DOORs databases. Immediately after, the entire databases are piped to two tarfiles, capturing absolutely everything. Once the tarfiles are generated, the databases go back online, and the tarfiles are then sent to tape. The overall downtime is very minimal.. Also, our DOORs project managers perform manual archives of whatever DOORs data they are responsible for. We have not automated this yet, but any tips would be appreciated.
An aside to this, is that the nightly tarfiles are also extracted to a backup server, which also runs DOORs v5 and DOORs v6. This way, we have a backup server available with data 1-day old. This provides an excellent test platform, for attempting operations in DOORs which may cause problems in the "real" databases. Our databases are currently small --- combined, they are 600megs (compressed with gzip)... --Scott Catterill --DOORs Database Admin, for General Dynamics Canada (Ottawa) --scott.catterill@gdcanada.com |
|
![]() |
|
![]() |
|
As Sutherland suggested auto-running project archives has its own problems. Our solution is to have the DXL remove all locks in the database, then archive all the projects, and hope nobody logs into DOORS between 11pm and 2am. Once the archive script is written we wrote a DOS Batch file to invoke it "in batch mode", then used some NT command to run the Batch file everyday at 11pm.
But lets say project archiving each night is out of the question but the NT folk do file system backups. When you have a problem you could restore last nights back-ups to a different folder structure on (lets say) your own private machine. You then have a copy of the entire DOORS DB. Now run DOORS locally to this copy. Then archive the project in question; purge the live (corrupted) project, and restore the just archived one. You are only greatly inconvenienced when there is fatal corruption. This will, of course, erase any work this morning in THAT project but won't affect any other projects. Except, of course, any inter-project links will be gone. - Louie |
|
![]() |
|
![]() |
|
<< Our solution is to ... and hope nobody logs into DOORS between 11pm and 2am. >> You can significantly increase your chances by taking the server down and then bringing it up on a "secret" port to complete the archiving. Of course, you may have other restrictions that I don't know about. We use this technique anytime there is a need to perform work with a Doors Client and we don't want other users interrupting the processes. - Boyd Boyd McKillican T-Systems GEI GmbH Email: boyd.mckillican@t-systems.com Internet: www.t-systems.de ------------------------- Boyd McKillican T-Systems GEI GmbH Email: boyd.mckillican@t-systems.com Internet: www.t-systems.de |
|
![]() |
|
![]() |
|
Amy,
We have automated the backup of our doors server, as follows. A set of crontab job fires every night: 0 1 * * 2,3,4,5 /bin/tcsh autobackup.tcsh daily 0 1 * * 1 /bin/tcsh autobackup.tcsh weekly 0 1 1 * * /bin/tcsh autobackup.tcsh monthly The autobackup script removes (with no remorse) any locks that still exist. It then generates a project archive for each project in the database. These archives are stored in a round robin fashion into directories daily, weekly and monthly: daily has 5 subdirs, weekly has 5 and monthly has 12 dirs. If/when a backup is needed, you can restore on a per-module basis. This backup scheme (together with a normal backup of the full file system) gives us sufficient piece of mind... Ron. Ron Sprenkels Requirements engineer, DOORS administrator _________________________________________________ LogicaCMG Colosseum 2 7521 PT Enschede www.logicacmg.com P.O. Box 268 7500 AG Enschede +31 53 482 4216 Fax: +31 53 482 4500 |
|
![]() |
Telelogic DOORS
» Enterprise Operations
»
DOORS Database Backups
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.