All About the Apps
Showing results for 
Search instead for 
Do you mean 

The snakebite prevention kit for backing up your ALM

Michael-Deady ‎02-07-2013 10:06 AM - edited ‎09-18-2015 04:04 PM

I 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.


There’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


Restore Requires

Full   or Incremental level 0


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


Cumulative   incremental level I


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



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.


Directory 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.







About the Author


Michael Deady is a Pr. Consultant & Solution Architect for Teksystems, center on quality, aimed at client's satisfaction, and long-term success. Perceived by clients, peers, and supervisors as a leader with the proven ability to lead development and quality assurance teams through software-development life cycle phases, to ensure quality of new products. He specializes in software development, testing, and security. He also loves science fiction movies and anything to do with Texas.

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all