The snakebite prevention kit for backing up your ALM

background-example-wht-logo-blu-bg.pngI compare this topic to hunting for rattlesnakes; it can really get your blood pumping, but after turning over X numbers of rocks looking for that elusive rattlesnake you become complacent and even bored at times. But when you finally turnover that  one rock and 100 little baby rattlesnakes scramble out in every direction it is enough to give you a heart attack. Hopefully you brought an extra set of clothes with you or its going to be a long and very uncomfortable drive home.

 

Note to Reader: while this article is directed at ALM site administrators, it could pertain to any application that you or your team supports. In other words the acronym ALM could be interchangeable with PPM, ITSM, PC, JIRA, MS TS, etc…

 

One of the key questions ALM site administrators (SA) always ask me is how often should they backup the databases and file repositories for each project. This question may seem like a straightforward and easy question to ask. However, this question can have anywhere from a simple ROI perspective to legal ramifications. I’m more than happy to give you some guidelines, but by no means assume that this article is anything more than just a list of tips and questions that you as a SA need to ask your customers and your IT legal department.

 

ALM11.jpgThere’s two parts to backing up the and ALM project :

  1. The first item is the database and its tables which contains most of the key information—either displayed in the web interface with all of the logistical information needed for the releases, risk management, traceability matrix and links to the repository.
  2. The second item that needs to be backed up is the file repository; which you can locate in the ALM site admin project area and then select the project details tab.

 

TIP: If the system goes down and you cannot access the ALM site admin database, you can find most the information you’re seeking. This includes the location of the file repository and database name in the DBID.XML file under the name of the project you are looking for which may include a numerical number at the end.

 

When doing full backups (daily, weekly, monthly) of the files repository and the project database they should be backed up at the same time to avoid any synchronization errors between the file repository and database. Errors (broken links, missing information or files) typically happen when the information is uploaded, updated, or deleted from the file repository during the lapse of time between the backup of the file repository and project database. Most of the time it can be physically impossible to match up the file repository backup and project database at the same time. Because of this we recommend that you schedule project outages for those given projects in which the file server and database can be scheduled for automatic backup.

 

Key Database and files

 

I want to address the highest priority first.  One of the simplest, (but highest priority) is the “QCsiteadmin” database which drives the key configuration of ALM and also includes the users table. This can be backed up on a monthly basis, unless you have a key configuration change or add more than 10 to 15 users per week.

 

At that point I would recommend backing it up on a weekly basis. I would also recommend keeping at least four to six months of monthly backups of the “QCsiteadmin” database on hand—just in case of catastrophe failure and/or support issues that you may encounter over that period of time. For the most part, your repository (other than logs) has no direct impact on the site administration table. I would also recommend a complete SA directory structure backup monthly for any anomalies and support issues.

 

Templates projects

 

While similar to a typical ALM project, the template projects do not or should not contain any specific project data—other than skeleton or foundational data needed for any given project. That said, all template projects should be backed up dependent on how often they are redesigned or pushed out to subordinate projects. A good rule of thumb is to schedule the backups for both the repository and database of templates to coincide with the push of the new template configuration.

 

Types of backups

 

Knowing the types of backups that are at your disposal is almost as critical is as critical as scheduling your backups:

 

Database Backup and Restore:

 

Oracle backups

SQL Server Backup

Description

Restore Requires

Full   or Incremental level 0

Full

This   is a complete backup of the database, which includes all objects, tables and   data. This process can be very time-consuming and require the database to be   down for great links of time

N/A

Cumulative   incremental level I

Differential  

This   backs up any data that has been changed since the last full backup. The   amount of time to backup depends a lot on how often a differential is   scheduled in the amount of data stored in the database during that period of   time.

A   differential only requires the last full backup and the last differential   taken. This is not cumulative

Differential   incremental level I

Transactional   (T – log)

This   only backs up the transactions that occur during a given period of time.

T   – logs require a minimum one full backup and one differential or all the T-logs   since the last full back-up or differential. This is cumulative and may   require multiple T-logs to be run before the data is fully restored and   sometimes can be Time-consuming.

  

Note: Your database administrator may use different terminology. This is based on support documentation from either Oracle or SQL Server in general terms.

 

File repository backup and restore:

 

Type of backup

Description

Restore

Daily   (not recommended)

A   daily backup copy of all the files that you select. These files have been   modified on the day the daily backup is performed. The backed-up files are   not marked as having been backed up (in other words, the archive attribute is   not cleared).

Dailies   are useful if you want to back up files between normal and incremental   backups, because a daily does not affect these other backup operations.

Differential   (not recommended)

A   differential backup copies files that have been created or changed since the   last normal or incremental backup. It does not mark files as having been   backed up (in other words, the archive attribute is not cleared).

If   you are performing a combination of normal and differential backups,   restoring files and folders requires that you have the last normal as well as   the last differential backup.

Incremental   (recommended)

An   incremental backup backs up only those files that have been created or   changed since the last normal or incremental backup. It marks files as having   been backed up (in other words, the archive attribute is cleared).

If   you use a combination of normal and incremental backups, you will need to   have the last normal backup set as well as all incremental backup sets to   restore your data.

Normal   (recommended)

Normal   backup copies all the files you select and marks each file as having been   backed up (in other words, the archive attribute is cleared). This method is Time-consuming   and difficult.

With   normal backups, you only need the most recent copy of the backup file or tape   to restore all of the files.

 

alm directory.jpgDirectory structure versus database structure

 

It’s easy to understand that the repository structure doesn’t always correlate directly with the database structure—which can be confusing at times. The best way to manage this is by creating a document similar to the figure called “Repository”. Remember that anything associated with the “QCsiteadmin” database and logs can reside in both the SA and QC directories of the repository. Most of project information, excluding some ancillary information, should only be stored on the QC directory side of the repository.

 

Quick Tip: look in the SA logs if you’re looking for the logs that contain system information and user information. For project specific errors, you must look under the QC error logs will.

 

You are probably asking yourself what snake wrangling has to do with backing up your data. In part two of this article, we will go into more detail about things to consider when setting up your backups and restores. You want to prepare yourself so if you have an outage or corrupted database your data won’t come back and bite you in the posterior. Remember when it comes to preparing the smallest of databases, it’s easier to restore than repair.

 

While ALM is a stable platform, inevitably you’ll have users that can’t help but lose, delete or corrupt information. A safeguard is to have version control or heavy security built-in into workflow. Even with safeguards in place, the likelihood that you’ll need to restore project becomes unavoidable. It’s not been my honor to work with some of these fine characters and would like to hear from you some of those with stories of lost or corrupted data.

 

If you are looking for additional help or support, feel free to reach out to my colleagues in HP Professional Services. We have the experience to help you with any situation you may have in your environment.  

 

In this article we covered the basic structure of ALM database and file repository. In the next part of this series on snakebite prevention, we will cover items that you will need to consider when setting up individual project backups and the risk that are associated with those choices.

 

HPblogfooter.jpg

 

 

Thanks

@wh4tsup_Doc

thCAIY2RL6.jpg

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Michael Deady is a Pr. Consultant & Solution Architect for HP Professional Service and HP's ALM Evangelist for IT Experts Community. He spec...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.