Backup and restore procedures
Here you can find information about the backup procedure for the BIND server configured by the debops.bind Ansible role and instructions for restoring the backed-up data.
Backup snapshots
The debops.bind role installs the debops-bind-snapshot shell
script that can be used to create periodic .tar.gz
archives of the
configuration and zone files used by the BIND server.
By default, three cron jobs will be configured by the role to create
daily (7 days), weekly (4-5 weeks) and monthly (12 months) snapshots of all
zones, keys and configuration files. Ephemeral data (i.e. files under the
/var/cache/bind/
directory) which can be recreated by the server on its
own (e.g. secondary zones, root keys, database dumps, etc) is not backed up.
This can be controlled using the bind__snapshot_enabled
and
bind__snapshot_cron_jobs
default variables. Alternatively, the
periodic cron jobs can be disabled, and the
debops-bind-snapshot script can be executed as root
to create
snapshots manually; previous snapshots are automatically removed in this case
with assumption that they have been transferred to a remote storage by other
means.
The debops-bind-snapshot script will enable and disable read-only mode for the named server (i.e. disabling dynamic DNS updates) and also attempts to determine whether named is already in read-only mode (in which case dynamic DNS updates will not be automatically disabled, under the assumption that the administrator has manually disabled such updates).
The snapshots are stored in the /var/backups/bind/
directory as
compressed tarballs. After finishing the snapshot, the
debops-bind-snapshot script will change ownership of the created
tarballs to the backup:backup
UNIX account and group. This account can then
encrypt the tarballs via its own set of scripts, using GnuPG asymmetric
encryption, to prepare them to be sent to a remote location (this functionality
is not implemented by the debops.bind role). The
debops-bind-snapshot script will automatically remove periodic
*.gz.asc
or *.gz.gpg
files before creating new iterations to
preserve disk space.
In general, the debops-bind-snapshot script works in a manner similar to that of the slapd-snapshot script from the debops.slapd role.
Restore procedure
The BIND server has crashed and burned, but you have the backup snapshots
available, how to restore them? The approach described here assumes that all
configuration was performed using the debops.bind role and is still
available in the inventory; only the backup of the zones, keys and
configuration is needed (strictly speaking, the configuration data should be
possible to recreate from the Ansible inventory, but the /etc/bind/
directory is anyway backed up since BIND keys and associated data, including
any manual configuration, is kept under said directory).
tl;dr version
Before running the debops.bind role on the new host, copy a backup file to the host and extract it:
# scp bind_month08_August.tar.gz new-bind-host:
# ssh new-bind-host
# sudo systemctl stop named.service
# sudo rm -rf /etc/bind /var/cache/bind /var/lib/bind
# sudo tar zxfv /home/user/bind_month08_August.tar.gz -C /
# exit
# debops run service/bind -l new-bind-host
Once debops run finishes, the new BIND installation should contain all the old zones and configuration. It might take some time before all secondary zones, etc, have been transferred.
Detailed explanation
The
tl;dr
version above includes sudo systemctl stop named.service as a precaution. Ideally, BIND should not be installed at all when you restore the backup. The reason for this is that as part of executing the debops.bind role, missing keys will be detected, new ones will be regenerated and copied to the server. Restoring the backup before running the debops.bind role means that the old keys will be detected and new ones will not be created. Should the keys get out of sync between the BIND host and the Ansible controller, the best solution is probably to remove the keys on the controller (under thesecret/bind/
hierarchy) and on the remote host (under the/etc/bind/keys/
hierarchy).Unpacking the compressed tarball with the
-C /
option means that tar willchdir
to the root directory before unpacking the tarball, which means that the backup (which uses relative paths) will be unpacked to the correct location.If BIND isn't running after debops run service/bind finishes, start named manually on the remote host:
# systemctl start named.service
Monitor the output from named to make sure that it accepted the new configuration and did not refuse to load any zones:
# journalctl -u named