Backup, restore, and recovery problems

Description

At the end of an HSM file system recovery, some files are reported as being 'reserved' in the output of the ivdrecover command.

Explanation

The word reserved means that file IDs were assigned to new files on the HSM file system, but these files had been either deleted or changed before they could be migrated using these particular file IDs. Such file IDs were only recorded in the File System Catalog. These files have been migrated using other, newly generated file IDs. The reserved entries therefore do not indicate data loss.

Workaround

None

Description

After the OA restore process successfully completed, OA processes cannot be started on the consolidated OA system or OA server.

Explanation

The most probable cause of this problem is that some files on the consolidated OA system or OA server were either struck by disaster or accidentally deleted, and these files were not backed up during the OA backup process. OA backup images do not include files from the OA installation which are not updated during OA operation. OA backup configuration file backup.cfg is not backed up.

Workaround

Before starting the OA restore process, repair the OA installation. The repair process will replace corrupt or missing OA installation files.

Proceed as follows:
1. Repair the installed OA software by using the rpm -F command.
For details, see the OA Installation Guide for Linux, chapter ”Installing OA software”, section ”Identifying, verifying, and repairing the installed OA software”.
2. Using the ivdrestore command, start the OA restore process again.
3. Optionally, check and modify values in the OA backup configuration file backup.cfg.

Description

After an OA backup process is aborted or the OA server is restarted due to power outage, new OA backup cannot be started.

Explanation

The aborted OA backup process did not remove the lock file backup.pid from the lock directory. This file is used to prevent starting another backup process while the first backup process is still running.

Workaround

After verifying that no other OA backup process is running at the moment, manually remove the file backup.pid and start OA backup once again.

Description

After you restore the OA server from a tape medium that stores only one OA backup image, the status of the medium will be 'empty'.

Explanation

At the time when the backup was started, the tape medium was empty. Since restore reverts the complete OA server state to the moment when the backup was initiated, the statuses of backup media are also reverted.

Workaround

As this situation will resolve automatically after a new backup image will be created on the same medium, you can ignore the erroneous status.

Description

OA backup fails and the following entries are reported to the terminal window and logged in the backup.log file (the volume and partition names may be different):
[2006/03/02 22:39:20] Volume /dev/vg_ivd/part: Creating snapshot...
[2006/03/02 22:39:20] ERROR: SnapshotsMgr error.
[2006/03/02 22:39:20] Unsuspending partition...
[2006/03/02 22:39:20] Partitions fs1: Unsuspended.
[2006/03/02 22:39:20] Finished unsuspending for all partitions.
[2006/03/02 22:39:20] Backup job stopped.
[2006/03/02 22:39:20] ERROR: Backup failed: 9, Creating snapshot /dev/vg_ivd/part failed! Return value 3

(SUSE Linux Enterprise Server system specific)

Explanation

The module dm-snapshot was not loaded at the time when OA backup tried to create volume snapshots.

Workaround

You need to load the module and configure its automatic loading at subsequent system startups. To load the module, invoke the following command:
# modprobe dm-snapshot
To configure automatic loading of the module at subsequent system startups, add the string dm-snapshot to the variable MODULES_LOADED_ON_BOOT in the file /etc/sysconfig/kernel, like shown in the following example:
## Type: string
## ServiceRestart: boot.loadmodules
#
# This variable contains the list of modules to be loaded
# once the main filesystem is active
#
MODULES_LOADED_ON_BOOT="dm-snapshot"