This is the documentation of an old opsi version. The documentation for the current version 4.3 can be found here.

opsi-backup

Introduction

Like any other system, an opsi-system should also be backed up. Since opsi is a central tool for Windows client and Windows server management, the opsi-server should be backed up. This manual is intended to give an insight into the backup strategy of opsi and also on topics such as restoring and the "DisasterRecovery" of opsi.

Preconditions for a backup

There is not really a prerequisite for backing up an opsi-system. Once you have located the central files and backends of the opsi system, you can save them using various methods. The following instructions should not only answer the question: "What should be backed up?", but also document a way what a backup strategy for an opsi-system could look like.

The backup script should be run as root, either manually or a root cronjob, so that you can read the configuration of opsi and also determine the system configuration. Furthermore, the mysqldump program should be installed for a backup of the mysql backend, which can usually be found in the client packages of mysql.

Quick Start

Creating a backup:

opsi-backup create opsi_backup.tar.bz2

Creates a backup of the currently used backends, as well as the configuration files, in the current directory with the name opsi_backup.tar.bz2.

Restoring backend data (without configuration files):

opsi-backup restore opsi_backup.tar.bz2

Restores the data from the backup file opsi_backup.tar.bz2 in the current directory.

Completely restoring a backup including configuration files:

opsi-backup restore --backends=all --configuration opsi_backup.tar.bz2

Basic parts of opsi

Opsi can roughly be divided into five parts. The following five parts are specific to opsi and may vary from system to system depending on the configuration.

Opsi configuration

By far the most important part of opsi is the configuration. True to LSB (Linux Standard Base), the configuration of opsi is located under /etc/opsi.

This directory mainly contains the backend configuration, the webservice configuration and the SSL certificate for the webservice. Furthermore, backend extensions are stored here, the configuration of 'opsipxeconfd', 'opsi-package-updater' with its repositories and also the modules file, which unlocks your co-financed modules.

The directory /etc/opsi must be backed up in order to achieve a full recovery after an incident.

This part is secured with opsi-backup.

This backup also has another advantage:
If you have changed many configuration options of opsi and the system no longer works properly, it is usually easier and quicker to return to a previous working version than troubleshooting.

Opsi backends

The opsi backends are listed in the following chapter. These form the heart of the opsi data storage. All clients, products, configurations, statuses, etc…​ are stored in the respective data storage.

Opsi offers the following data backends:

Table 1. opsi backends
Backend Description

file-Backend

File-based backend, currently the default

mysql-Backend

MySQL-based backend (since opsi 4.0)

dhcp

Special backend which is used in combination with dhcpd on the opsi-server

If you do not know which backend you are using, you are probably using the file backend. Opsi is also designed to use multiple backends at the same time. Which backends are used for which functions of opsi is configured in /etc/opsi/backendManager/dispatch.conf.

This part is secured with opsi-backup.

Opsi depot share

The depot files are interesting because they contain the actual files of the software to be distributed. The localboot products as well as the netboot products each have their files stored under /var/lib/opsi/depot. In previous versions of opsi they were located in the directory /opt/pcbin/install.

Depending on how much software is kept on the opsi-server, and how many operating system installations including drivers are stored, this data volume can take on enormous proportions.

There are different approaches to back up these files. The simplest alternative is 'rsnapshot'. However, there are more elegant solutions, such as storing this data in a redundant file system on a SAN, etc.

This part is not backed up by opsi-backup.

Opsi workbench

The opsi workbench area, which is also used as a Samba-share of the same name ('opsi_workbench'), contains the state of your own software packaging. By default, the directory is /var/lib/opsi/workbench. If this share is used to store your created packages in different revisions, this directory should also be saved.

The 'rsnapshot' tool is also suitable here.

This part is not backed up by opsi-backup.

Since opsi 4.1, this directory can be configured individually for each depot server, so that different paths are possible.
Before opsi 4.1, this directory was on non-SLES systems located at /home/opsiproducts.

Opsi repository

The directory /var/lib/opsi/repository is used to store opsi packages. Unlike the opsi workbench, it is not used to create opsi packages, but the opsi packages that are stored there should not be removed, in order to simplify a possible synchronization with other servers or the synchronization using opsi-package-updater.

These files are not absolutely necessary for a complete recovery, but can also be saved with the 'rsnapshot' tool.

This part is not backed up by opsi-backup.

TFTP directory

The TFTP directory contains configuration files for booting via PXE. This directory is located under /tftpboot/ on most systems. On SLES this directory is /var/lib/tftpboot/opsi/.

Possibly modified files are e.g. linux/pxelinux.cfg/default.menu or linux/pxelinux.cfg/default.nomenu. These files are created with default values when installing opsi-linux-bootimage. These are not absolutely necessary for disaster recovery.

This part is not backed up by opsi-backup.

The opsi-backup program

The command line program opsi-backup is a tool that makes it easy to create and restore backups.

To do this, opsi-backup can be controlled with three basic commands: create, restore and verify.
The --help option gives a detailed overview of all options of opsi-backup.
A backup created with opsi-backup is a raw backup, which means that no files are backed up at the logical level, but backups of the files stored in the backends are made in the corresponding structures.
Such a backup can therefore only be restored for an identical backend configuration.

A backup created with opsi-backup is always a full backup (opsi-backup does not support incremental or differential backups).

It should be noted that opsi-backup does not back up depot files, workbench files and repository files. These files should therefore be backed up in a different way.

The backup file created with opsi-backup is a compressed tar file, the content of which can be viewed accordingly.

opsi-backup --help
A backup created with opsi-backup may contain passwords and PC-keys, among other things, and should therefore be stored securely.

Creating a backup

A new opsi backup is created with the command opsi-backup create. If this command is given without further parameters, the program creates an archive with all data of the backends and the configuration. The file name is generated automatically. Additional program help is available for the opsi-backup create command, which is output using the --help option.

opsi-backup create
opsi-backup create --help

It is also possible to specify the file name or the target directory of the new backup. To do this, simply add a file name or a target directory to the corresponding command. If a directory is specified, opsi-backup automatically generates a file in this directory. A file name generated by opsi-backup has the form <hostname>_<opsi-version>_<date>_<time> and is well suited for archiving several backups. If a file name is specified, an older backup with the same name will be overwritten by opsi-backup.

opsi-backup create /mnt/backup/opsi_backup.tar.bz2
opsi-backup create /mnt/backup/

In addition, the create command enables the backup to be controlled using the following options:

  • -- backends {file,mysql,dhcp,all,auto} + + Allows you to select the backends to include in the backup. This option can be specified multiple times to specify multiple backends. The option `--backends=all` includes all backends. The default for this option is `--backends=auto`, which means that `opsi-backup` tries to determine the backends in use using the configuration file `/etc/opsi/backendManager/dispatch.conf`. Currently, the following backends are supported: +mysql, file, dhcp

    opsi-backup create --backends=file --backends=mysql
opsi-backup create --backends=all
    If you are using an unsupported backend (such as 'ldap'), you can convert it with the command opsi-convert to a backend which can be backed up with opsi-backup.

  • --no-configuration
    Excludes the opsi configuration from the backup.

    opsi-backup create --no-configuration

  • -c [{gz,bz2,none}], --compression [{gz,bz2,none}]
    Specifies the compression method with which the archive is to be compressed. none stands for no compression, the default compression is bz2.

    opsi-backup create -c bz2

  • --flush-logs
    The backup of the mysql backend is done internally with a 'mysqldump' command. This means that the data is backed up exactly as the database is at that time (regardless of whether the data is already on disk or only in memory). Thus, the backup created may be more up-to-date and different from the state of the database files. If you want to avoid this, the data held in memory by mysql must first be written to disk. If the option --flush-logs is specified, opsi-backup will try to perform this operation (i.e. write the data from memory to disks). However, the corresponding database user of the opsi database needs the corresponding MySQL authorization RELOAD. By default, the opsi user is created without this right! If the user does not have this right (and the option --flush-logs is specified), the backup will fail. Therefore, only use this option if you have previously adjusted the rights of the database user.

    opsi-backup create --backends=mysql --flush-logs

    Example

opsi-backup create --no-configuration --backends=all opsi_backup.tar.bz2

Archiving backups

opsi-backup does not have any functionality for archiving backups. The administrator must therefore ensure that created backups are stored securely and versioned. In addition, opsi-backup never automatically deletes older backup versions (unless they are overwritten with create). Since opsi-backup always creates full backups and no incremental backups, the amount of data can quickly grow to a large size. The administrator must thus also ensure that older backups are deleted regularly if necessary.

Verifying a backup

With the command opsi-backup verify the archive can be checked for internal integrity. This check is not a logical check of the data, it is a pure check if the data stored in the archive is not corrupted. Additional help is available for the opsi-backup verify command, which is shown using the --help option.

Example

opsi-backup verify opsi_backup.tar.bz2
opsi-backup verify --help
If the opsi-backup verify command is explicitly ran on the console, it often makes sense to send the output of opsi-backup to the standard output (stdout): opsi-backup -v verify opsi_backup.tar.bz2

Listing the contents of a backup

With the command opsi-backup list the contents of a backup will be displayed. The listing shows whether configuration data is available, and from which backends data is in the backup.

Example

opsi-backup list opsi_backup.tar.bz2

Restoring from a backup file

Restoring an archive is done with the command opsi-backup restore. The backends are (by default) imported based on the current configuration. It is therefore not possible to restore a pure backend backup, if an opsi configuration is not available. The command opsi-backup restore needs a parameter, which is the backup archive from which data is to be restored. Additional help is available for the opsi-backup restore command, which is output using the --help option.

opsi-backup restore accepts the following options:

  • --backends {file,mysql,dhcp,auto,all}
    Specifies the backend to restore.This option may be used multiple times to specify multiple backends. The option --backends=all stands for all backends.
    As a default, the option --backends=auto is used, which means that opsi-backup tries to determine which backends to restore from the configuration file /etc/opsi/backendManager/dispatch.conf.

    opsi-backup restore --backends=file --backends=mysql opsi_backup.tar.bz2
opsi-backup restore --backends=all opsi_backup.tar.bz2
    If you changed your backend configuration since you have created the backup, the default setting will not restore up any data.

  • --configuration
    Restores the opsi configuration. This option is not the default for the restore command.

    opsi-backup restore --configuration opsi_backup.tar.bz2

  • --new-server-id=<new-name>
    Changes the name of the Opsi Config server after restoring the backup. If there is a host with the ID <new-name>, it will be removed.

    opsi-backup restore --new-server-id=test.example.org opsi_backup.tar.bz2

  • -f, --force
    Before restoring a backup, opsi-backup carries out a systemcheck to see whether the current opsi installation matches the installation of the backup (opsi version, OS version, host- and domain name). This option can be used to bypass this check.

    opsi-backup restore -f opsi_backup.tar.bz2

    Example

opsi-backup restore --configuration --backends=all opsi_backup.tar.bz2

If a backup is restored to a server and there is no backup of the depot folder, you can use opsi-package-updater and opsi-package-manager to download and install all packages from the repository again. Any changes made to the depot must then be applied again afterwards.

opsi-package-updater download --force
opsi-package-manager --install /var/lib/opsi/repository/*.opsi