Hotcopy Backup

{question}

Is there a way to back up a running database?

{question}

{answer}

The hotcopy backup is a distributed backup feature that can cause multiple SMs to create a coordinated backup of a distributed database;

If there is no user SGs defined, then every SM has a complete copy of the database, and any backup from any single SM can be used to restore the entire database; but if there are user SGs defined, then a backup from a single SM does not contain the entire database, and so a valid backup comprises multiple backupset directories; It means that when user-defined SGs are defined, a database restore requires multiple SMs to be restored and started simultaneously.

Hotcopy command allows you to obtain a copy of a running database.  This copy contains the state of the storage manager that it is run on as it was at approximately the time when the hot copy finished running.

To define/schedule jobs for backup, you need to understand the options of hotcopy and use them according to your need in case of recovery from backup, to which level of accuracy you have to recover your database.

Types of hotcopy process: Full, Incremental, and Journal. Every type of hotcopy process creates a transactionally-consistent copy of an SM.

Full hotcopy backup -

A full hotcopy backup includes every storage group copy that can be used to recover the whole database data once we run restore from backup.

A full hotcopy of an archive in size is approximately the same size as the archive being hot copied at the time the hotcopy finishes, plus the size of the journal of the SM at the time the hotcopy finishes.

Incremental hotcopy backup -

An incremental hotcopy creates a space-efficient, transactionally-consistent copy of an archive that stores only those atoms that have changed since the previous full or incremental hotcopy in a backup set containing hot copies of that archive.

An incremental backup requires a full backup first in the backup-dir path, otherwise, you will get an error message:

'hotcopy database' failed: Failure while performing hot-copy: Error while sending engine request: Cannot create incremental element. No full hotcopy exists in backup set

Journal hotcopy backup -

A journal hotcopy creates a transactionally-consistent copy of the changes in an archive since the previous journal hotcopy. Journal hotcopy enables point-in-time restore, allowing restore to a chosen transaction. To use journal hotcopy with an SM, the SM must start with the option '--journal-hot-copy enable', if not you will get the following error message when taking a journal hotcopy

'hotcopy database' failed: Failure while performing hot-copy: Error while sending engine request: --journal-hot-copy disabled in node 1 configuration

An SM which started with the option '--journal-hot-copy enable' will retain each journal files on disk until it is journal hot copied into a backup set. This may exhaust free disk space on the journal device thus you need to plan the journal hotcopy accordingly.

 

Recommendations:

  • There should be at least 2 copies of each backupset
  • The copies should be in different data centers/regions/clouds if possible
  • If there are no SGs (Storage Groups) involved, then at least 1 backup copy in each data centre/region/cloud
  • If there are SGs involved, then at least 1 backup copy of each SG in each data center/region/cloud.
 

Number of SG

Number of SMs

center/region/cloud

Number of backup copies

0

2

1

1

0

2

2

2

0

4

2

2 (1 per DC)

3

2 each (6SMs)

N

N*(every SM)

3

4 (2 in each DC)

2

2 backups for each SG

The user is responsible to schedule the hotcopy backup, it is not set automatically. 

You may find more information about this topic by clicking here.

If you have any questions, please reach out by clicking here.  

{answer}

Have more questions? Submit a request

Comments