Bung technology


This page documents bung (BackUp Next Generation).

bung is a set of wrapper scripts for several backup utilities:
  • OpenLDAP (slapcat and tar)
  • mysqldump
  • pgdump
  • rsync
It also has
  • A "sysinfo" facility to generate system information reports
  • Templated backups allowing custom backup commands. Example templates are provided for Cisco switches and MikroTik routers
  • bung was developed and is supported on Debian computers. It was used extensively on Ubuntu computers and should run on other Debian derivatives with no or little adaptation.
  • Given that bung uses standard GNU Linux tools (it is written in bash) and is available as a tarball as well as as a .deb, it should run with little adaptation on other Linux distros.
  • Automated backup to hotplug devices when they are plugged in with on-screen notifications to both character terminals and X displays.
  • Backup to remote file systems via ssh
  • Custom commands (hooks) to run before and after the backup itself
  • File system hierarchy standard (FHS) compliant
  • GPLv2
  • Logging designed to ease production support
  • LVM snapshots
  • man pages
  • Mounting and unmounting local file systems
  • Remote ssh command validation

bung development began in 2013. It has been in continuous production use since then. In Dec 2019 it was known to be used on 100+ computers.

Related documents


From .deb

Installing from .deb is simpler and automatically installs dependency packages and, according to the local apt configuration, installs recommended packages.

The User Guide (links above) has detail on packages which are required and optionally required. You may want to install optionally required packages which are not installed via the .deb.

To install or upgrade, change to the directory containing the .deb and run the following commands, changing the version as appropriate.

apt install ./$deb


Installing from tarball is more flexible than installing from .deb but does not install packages which are required and optionally required.

The User Guide (links above) has
  • Detail on packages which are required and optionally required
  • Instructions on installing from tarball


By default, configuration is by files in /etc/bung

Configuration is documented in:

  • The User Guide (links above) has detail on configuration and a "Worked examples" section. After installation, the User Guide is installed in /usr/share/doc/bung
  • The commented sample configuration files installed under /usr/share/doc/bung/examples
  • man pages, conveniently listed by man -k bung


There are three types of bung-related email:
  • Report emails generated directly by bung
  • Emails from (ana)cron
  • Emails from logcheck

Only the first are generated routinely, that is when there is no warning or error.

The User Guide (links above) has detail on bung-generated email.

Emails from (ana)cron

Apart from backups started by plugging in hotplug devices, bung jobs are initiated by (ana)cron. In case backup is not successful, bung sets a non-zero return code which (ana)cron normally mails to root: 1 for a warning and 2 for an error.

Emails from logcheck

If logcheck is running, logcheck sends mail including bung warning and error messages written to syslog.


bung is a wrapper for standard backup utilities so restoring is done in the standard way for each as listed below.

Finding the backups

Backups may be local, remote and/or on USB HDD.

Backups are usually initiated locally; sometimes they are initiated by a remote computer ("pull" backups).

If the backups are initiated locally, the logs are in /var/log/bung and identify where the backups are written.

If the backups are initiated remotely (pulled), the remote system can be normally be identified by its public key for the backup being in /root/.ssh/authorized_keys or authorized_keys2 (which should have an indicative comment as the last word on the line).

For restoring MySQL (including mariadb), OpenLDAP, and postgres backups, standard procedures are used.


The first step is to find the backups:
  • Push and local backups: examine the restore client's /etc/bung files
  • Pull backups: examine the puller's /etc/bung files. In case the puller is not known, examine the restore client's /root/.ssh/authorized_keys and authorized_keys2 for the puller's public key (which should have an indicative comment as the last word on the line)

Problem analysis

Log inspection

The logs are in /var/log/bung.

The User Guide (links above) has detail on using the logs.



Is bung monitoring working? It is all done by email and there is plenty that can go wrong with email.

TODO: devise a system (manual/automatic?) to check when a report email was last received.


What is being backed up?

In case the backup file system is not normally mounted, it must be mounted. The easy way is to use values from a Mount line in one of the relevant configuration files. They can be listed by:

grep -Ei '^[[:space:]]*Mount[[:space:]]*=' /etc/bung/*

Once the backup file system is mounted, it can be helpful to:
  • Sanity check backup data volumes using the likes of du -hs
  • Review what is under each "_Changed and deleted files" directory.

Can files be restored?

The ultimate test of a backup is to restore from it :D