The following topics describe how to internally back up and restore your Tamino database in case of any failure that can occur on your system: disk failure, program failure, or human error. When you perform an internal backup in Tamino, all data in the database is written block by block. The following topics are covered:
An internal Tamino backup can be a full backup of the whole database, or it can be an incremental backup that records the changes since the last full or incremental backup. When developing a backup strategy, apply this principle: the more often your database changes, the more often you should save it. If, for example, your database is very active, you should make daily backup copies. The backup is done online, which means that the server is running, so you do not even have to stop the database when backing up, or notify your users. After a full or incremental backup, a new Tamino log space is started automatically. Backups can also be done in read-only or stand-by mode. This kind of backup that is done while it is not possible to update the database is called offline backup.
Incremental backups provide a useful extension to Tamino's backup capabilities. If you decide to include incremental backups in your backup strategy, you should keep a sensible balance between incremental backups and full backups. Regular full backups should still be the central part of your strategy, and the incremental backups can be considered as a quick and safe way of protecting against data loss in the intervals between the full backups.
Generally, internal backups are done to another disk. If you have enough space on a disk other than your working disk, you should back up to a disk as your preferred method. This saves time and effort.
 |
Warning: Please note that when you delete a Tamino database, all backups of the database are also deleted if the option Keep Backups has not been specified. |
To create a backup of a database
Follow the steps described in section Database Backups in the documentation of the Tamino Manager.
One important aspect to consider when backing up is the number of backup generations that may co-exist (the default value is 5). If you have enough space on your storage device, a recommendation for the number of backup copies is 7, which means one backup for each day of the week. After the seventh backup, the first one will be deleted, including the log spaces and everything else belonging to the backup.
Why should you have more than one backup? The last backup is always taken as the default, because it takes the least time for the subsequent Recover step. The backup(s) before that should only be used if the most recent backup is not usable. Security increases with the number of backup copies available.
If you use incremental backups as part of your backup strategy, note that incremental backups are not counted as additional backup generations. A backup generation can be thought of as a full backup plus all of the associated incremental backups. A new backup generation begins when a new full backup is made.
Note:
Note that newer backups will be removed when an old backup had been
restored and the database has been modified.
If you perform a database restore without recover, using a backup that is not the most recent backup, all subsequent backups of the database are set automatically to disabled.
Disabled backups are ignored when Tamino counts the number of backup generations for a particular database.
You can use a disabled backup to create a database, using the command
Create Database from Backup, but otherwise a
disabled database cannot be used any more.
Note:
There are currently no direct features for deleting a disabled
backup. However, a disabled backup will be automatically deleted when there are
no more older non-disabled backups.
To be prepared for certain types of disk failures, you need to be able to recover everything on your system.
The process of regenerating your data from a backup is done in two steps: First, the restore step, which is the reverse procedure of a backup. As input, you use the backup copy of the database, which automatically restores your data back into the database. The second step, the recover step, repeats database changes since that last backup by using the session logs stored in the log spaces.
A restore is always done for the whole database, not for parts of the database, e.g. for single collections. When you restore from a full backup, the database contents are returned to their exact state at the time the full backup was made. If you restore from an incremental backup, Tamino first restores the most recent full backup that was made before the incremental backup, then restores any other incremental backups that were made after the full backup but before the selected incremental backup, then finally restores the selected incremental backup.
As soon as the restore step successfully finishes, the database is automatically started in standby mode. Then the recover step is started. During the recover step, all of the completed database transactions that were made since the specified backup are recovered. The input for the recover step are the log spaces; each server session creates a log space that records all completed database transactions that are made during the session. By using the Recover Until option, you can restrict the recovery until a certain date and time.
If you restore from a full backup, the subsequent automatic recover step uses only the session logs, even if there are incremental backups available that were made after the full backup.
If you restore from an incremental backup, then Tamino restores first the corresponding full backup and then all incremental backups up to and including the selected incremental backup. The subsequent automatic recover step uses the session logs that were created after the selected incremental backup. Incremental backups that were made after the selected incremental backup are not used in the restore or recover phase.
Tamino processes incremental backups faster than session logs. Therefore, if you have made a full backup and one or more subsequent incremental backups, then you should select the most recent incremental backup for doing the restore instead of selecting the full backup.
The log spaces are located in the folder "<INSTALL_ROOT>/Tamino/db". During a mass loading process, the necessary information is written to so called "Utility Recovery Spaces". These spaces are handled like log spaces during the recovery step.
An important aspect when restoring and recovering data is the consistency of the database. In Tamino, you can be assured that even if it was not possible to recover all changes, the database is consistent. Transactions are recovered in an "all-or-nothing" fashion. The log spaces carry a timestamp so that you can recover your data up to a certain point in time, e.g. before an application error occurred.
Also, it is possible to restore a backup of a former Tamino version, whether the older Tamino version is installed or not.
Note:
During the Restore/Recover step the database is in standby mode,
which means that it is not possible to work with it. Hence before and after
changing large amounts of data at one point in time, it is recommended to back
up the database. Otherwise, the Restore/Recover step might take very long, and
the database is not available for that period of time.
When you do a Recover, you have the choice between three possibilities: Recover all, Recover until, and Don't Recover. In an error-free situation, you naturally would recover all changes made to the database since the last backup. The other two options are to be used if an application error occurs, or if the Restore/Recover step is not successful.
Restoring data is just the reverse of backing up data. The data saved in the backup copy is put back to where it belongs. Possible error situations for restoring database backup copies are for example:
The last backup copy was accidentally deleted, or cannot be found.
The last backup copy is corrupt.
In all these cases, it is important to have a good backup strategy. If you have several backup copies, go back to the most recent one that is not corrupt, and do a Restore/Recover.
For the Recover step, though, other error situations may occur:
Some or all log spaces are missing for the Recover step.
The server process is aborted while the Recover process is running.
If there are no or not all log spaces available:
The first case might occur due to a hardware failure or to human error. Maybe someone has deleted or renamed the log spaces accidentally, or the directory no longer exists. If at least some of the log spaces for the Restore/Recover process are available, Tamino processes that information up to a point in time just before information is missing or corrupt. In order to keep the database consistent, transactions that were still open when the error occurred are rolled back. After having recovered the available information, the server is stopped and shut down. The database is consistent, but not as current as it was before the error occurred. Notify your users to update the database manually.
If no log spaces at all can be found, it is not possible to recover any changes. In this case, the only possibility is to check the Don't Recover option and to just restore the database, without applying the changes since the last backup. Again, notify your users to update changes manually.
If the server process is aborted while the Recover step is running:
In the second case mentioned above, you have started a Recover step, but it is interrupted because the server is no longer available, e.g. due to a power failure. When you restart the server, several messages are displayed, informing you about the error status of the Recover step. At a certain point in time, you will be asked if you want to continue the server startup:
Please reply "yes" or "no" to continue server startupThe default is no. Reply no if you do not
expect that the Recover step will be aborted again (for example, if the reason
for the abort was a power failure). Redo the Restore/Recover step.
Reply yes if an abort will probably reoccur with a second
trial, for example if the reason for the abort was a corrupted log space. In
this case, you will be informed that restore of existing backups created after
the one used for the failed Restore/Recover run is not allowed any more. It is
still possible to retry Restore/Recover for the same or older backups. For
safety reasons, it is recommended to create a new backup immediately.
Alternatively, you could also reply no and do a Recover
until. Specify a point in time just before the server crash occurred, so
that the corrupted log space which contains the error is not used.
To Recover until a certain point in time
use the option in the inoadmin commandline tool, as described in section Database Backups. Enter the date and time until which you want the Recover step to run.
Note:
You can use the Recover until option also if
you are sure that an error occurred, e.g. due to a faulty application, or if
you want to delete parts of the changes that were made to a database and cannot
be deleted otherwise.
A backup always applies to a whole database. If you back up your data daily and keep your backups in a safe place, you cannot lose more than a day's work. With the Restore/Recover functions you have the possibility to regenerate changes made to the database after the most recent backup. The database will always be restored to a consistent state, but in very rare cases, errors might occur during the process. If an error occurs, there are two possibilities: Either apply changes only up to a certain point in time, or skip the whole recover step and just restore data back to the latest backup copy. In both cases, notify your users to update the database manually with the changes that were lost.