We just restored a QC project (Disaster Recovery), did we do it wrong?
| ♥ 0 |
We regularly backup/restore our project DB/Schema’s and corresponding project repository folders over to a disaster recovery server. Last week, we had an issue with a drive on our production server and since we had 2 copies of each project…the original one on the production server and a other backed-up one on the disaster recovery server, we pointed to it for our project’s DB/Schema and repositories. While our project was pointing to the disaster recovery server, some work was done in the projects. When it came time to move back, we copied the project DB/Schema back to the production server and brought it online as a separate projects so both were available on the prod server. So we had, for example, Project_1 and Project_1_DR to indicate the one that came back from disaster recovery. The reason for this was due to corruption on the disaster recovery server and we wanted to preserve the originals just in case. The issue came when we restored one of those projects. We accidentally pointed it to the original project's "repository"/file system rather than the repository we copied back from disaster recovery. So, we restored the project Project_1_DR (database) but pointed it to the file system for Project_1 (two projects pointing to the SAME repository folder). This project hasn't done any automation script work, but the users did create some manual tests while pointing to the disaster recovery project. So, basically, the project’s repository/file system is a couple of weeks older than the one the project should be using. We wanted to know, what are the potential impacts of this mistake?
Marked as spam
|
Posted by |
Private answer
It sounds like you might end up with an ''out of sync'' repository -- where the artifacts in the repository don't match (align with) the DB inventory of them. It may be too late now, but you should always keep the Project DB together with the corresponding repository from the same point in time of the backup (i.e backups made on the same night). If you have a copy of the repository that has additional artifacts not known to the current instance of the DB, you can use ''Realign Repository'' to try to remedy it. If you have items known by the DB that are supposed to be in the repository and are not, you may have issues when people try to access them (as attachments or test resource items). It is possible, though if you can identify which items they are and you have the OTHER copy of the repository, to copy items in and out of the repository. In QC9.x and 10, these files were stored as ''normal'' files in the repository folder structure. IN QC11 and later, we now have the ''optimized''/ ''Smart'' repository - you cannot see the files with a standard file manager, BUT you can get to them with an FTP client - See this other EyeOnTesting thread: http://eyeontesting.com/questions/4548/where-are-the-attachments-stored-in-almqc-11.html Marked as spam
 Posted by pt-barnum (Questions: 4, Answers: 509) Answered on October 28, 2014 8:38 pm
|