![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Resilient DOORS setup Topic Summary: Created On: 12-Dec-2003 13:34 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: I went through that issue with incremental backups. The issue is that even though physically the DOORS DB is made up of lots of files and directories, it's still a database and must be treated as a whole unit. With standard incremental backups, if you try to go back to a previous date, the danger is that you'll restore only some of the directories or files back to that previous date and you'll end up with an inconsistency in the database. You can do incremental backups, but if you do a restore, you MUST do a "point-in-time" restore, where you restore the ENTIRE database directory and all files and subdirectories in it back to the exact same point. If your backup software doesn't support "point-in-time" restores from incremental backups, then you can't use incrementals. Another way to think about it, think of a Microsoft Access database that's only a single MDB file. There, it's physically impossible to do anything except a full backup of that databse. That's they way you have to think about the DOORS database even though it's physically many files and directories. | |
![]() |
|
I have just been asked to look into how to deploy DOORS and I am concerned about how to make it resilient. I can have RAID disks etc. to minimise the risk of hardware failure, but it is impossible to totally remove the possibility of this happening, without a lot of money.
What does DOORS do in the case of a server failure, I cannot find anything in the manuals or on the web site ? I am used to an Oracle database that has archive logs that mean it can roll back/forward to fix problems. Is there a risk that I would have to resort to the previous nights backup, or possibly project archive as seems to be suggested on other threads ? Thanks Richard Stedham AMS Ltd |
|
![]() |
|
![]() |
|
I don't know of any roll-back/roll-forward utility. You can find a way to dump todays History of all modules, revert to last nights backup, then manually apply the History.
But if you had problems with just one module, you can restore the last nights backup to a temporary server, archive the module in question, then replace the corrupted live module with yesturdays. This means you only lose todays edits for that one module. This method, unfortunately, loses all links, especially the incoming links. - Louie |
|
![]() |
|
![]() |
|
Hi Richard,
I can confirm that the DOORS DB Server does not come with anything like the disaster recovery and management tools that DB engines such as Informix, Oracle and even MS SQL Server are equipped with. There has been a looooong standing request for DOORS to offer the choice of using open architecture DB engines such as the ones listed above. If it's of any consolation, the worst case disaster recovery position is that you will have to restore the DOORS DB data from the previous days tape back-up - as Louie has mentioned above, if a problem is more localised to a project within DOORS, then you can restore the previous days data somewhere else, connect a client to it and use archive and restore to replace the effected project/modules (some care is req'd with just replacing modules as these may have links which must also be included in the restore). ------------------------- Paul Miller Specification Practices Specialist, EuroCyber, Melbourne, Australia. Mobile: +61 (0)418 135 103 Web Site: http://www.eurocyber.biz E-mail: miller@eurocyber.biz">pmiller@eurocyber.biz |
|
![]() |
|
![]() |
|
Thanks, looks like the worst case is a days loss of work, if the server is backed up nightly.
|
|
![]() |
|
![]() |
|
I hope your doing full backups nightly. There seems to be a problem with incremental backups.
------------------------- Al Minter |
|
![]() |
|
![]() |
|
I went through that issue with incremental backups. The issue is that even though physically the DOORS DB is made up of lots of files and directories, it's still a database and must be treated as a whole unit.
With standard incremental backups, if you try to go back to a previous date, the danger is that you'll restore only some of the directories or files back to that previous date and you'll end up with an inconsistency in the database. You can do incremental backups, but if you do a restore, you MUST do a "point-in-time" restore, where you restore the ENTIRE database directory and all files and subdirectories in it back to the exact same point. If your backup software doesn't support "point-in-time" restores from incremental backups, then you can't use incrementals. Another way to think about it, think of a Microsoft Access database that's only a single MDB file. There, it's physically impossible to do anything except a full backup of that databse. That's they way you have to think about the DOORS database even though it's physically many files and directories. |
|
![]() |
Telelogic DOORS
» Enterprise Operations
»
Resilient DOORS setup
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.