logo
Powered by QM on a Rpi server
Home
About OpenQM
Sales and Downloads
Help and Support
About
Login

KnowledgeBase 00090: System Backup on QM

Last updated: 22 Jul 2016
Applies to: All versions
Search  
Top level index       Full Index Search Tips
Previous article     Next article

This article was originally published as a Tip of the Week.

Introduction

Historically, Pick style multivalue systems used the ACCOUNT.SAVE or FILE.SAVE tools to perform backups. These tools use a proprietary media format that is closely related to the implementation of the underlying Pick file system.

The QM file system is very different and, whilst these tools can be used to a limited extent for data transfer, they are not really suited to use for system backup. In particular, note that they cannot save ECS mode files or information relating to hashed file configuration, triggers, alternate key indices, encryption or replication. There are also limitations that affect saving of binary data.

Because QM uses the underlying operating system file structures to represent the QM data files, backup is best performed using operating system level tools exactly as would be done for other system data.


Backup Choices

There are many ways in which backups can be performed. Some examples are:

  • Copying the entire account directory to tape, DVD, remote disk, etc.
  • Incremental copy where only updated files are copied.
  • Creating a ghost image of the entire system.
  • Using snapshot backup technology.


Backup of a Live System

It is not always possible to get users off the system while a backup is performed. Conversely, it is impossible to create a reliable backup of a system that is changing as the backup progresses.

A backup performed by copying data while other users are actively changing it will almost certainly reveal data integrity problems if files are restored. There may also be structural problems caused by, for example, allocation of an overflow block whilst the file is being copied.

Snapshot backup technology resolves this problem by effectively taking a snapshot image of the database at a moment in time, ensuring that the backup process tracks changes made whilst it is running. Use of

   qm -suspend 
immediate prior to the backup and the corresponding resume as soon as the snapshot has started appears to yield a reliable backup. It may not.

Unless the point at which the suspend occurred maps onto a business transaction boundary in every QM process, there may still be data integrity issues though there will not be structural issues. The only solution to this is for the application to include coding corresponding in principle to the suspend/resume mechanism but aligned on a business transaction boundary.

Applications that use QM transaction processing will suspend on application level transaction boundaries but these may not line up completely with business transactions.


Related Articles

None.



Please tell us if this article was helpful
Very     Slightly     Not at all
Comments
Email (optional)