Backing up GLPI: files, MariaDB database, and cron-driven automation

GLPI (Gestionnaire Libre de Parc Informatique) holds your asset register, tickets, and configuration baseline — the kind of data you can't afford to lose. A working backup covers three things: the application files, any customized plugins, and the MariaDB database behind it. This guide walks through each, then shows how to automate the whole thing.

Step 1: Back up GLPI files and config folders

The GLPI application directory contains the core code, templates, and — most importantly — config/ and files/, which hold your installation's configuration and uploaded attachments. Copy the whole tree to a backup location:

cp -a /var/www/glpi /backup/glpi_$(date +%F)

Or compress it for transfer:

tar -czf /backup/glpi_$(date +%F).tar.gz -C /var/www glpi

Use cp -a (archive mode) rather than cp -R — it preserves ownership, timestamps, and symlinks, which matters for web file permissions on restore.

Step 2: Back up customized plugin folders and files

Plugins live in /var/www/glpi/plugins/ and are already included in step 1. If you've modified plugin code in place (not recommended but common), those changes are covered. If you maintain a separate plugin source tree or patches outside the GLPI directory, back those up too:

tar -czf /backup/glpi_plugins_$(date +%F).tar.gz /path/to/plugin-sources

Record the plugin versions installed. GLPI plugins are tightly coupled to core versions, and a restore to a different GLPI version may need the matching plugin build.

Step 3: Back up the GLPI database in MariaDB

GLPI stores tickets, assets, and relationships in MariaDB. Use mysqldump with --single-transaction so InnoDB tables are captured in a consistent snapshot without locking the application:

mysqldump -u glpi_user -p --single-transaction --quick --routines glpi_db | gzip > /backup/glpi_db_$(date +%F).sql.gz

A few notes on the flags:

• -p on its own prompts for the password. Avoid -p[password] inline in scripts — it leaks into shell history and process lists. For automation, use a ~/.my.cnf file with chmod 600.
• --single-transaction gives a consistent snapshot of InnoDB tables without a global lock. GLPI's default engine is InnoDB, so this works cleanly.
• --quick streams large tables row-by-row instead of buffering them — useful for bigger installations.
• --routines includes stored procedures. GLPI doesn't use many, but including them costs nothing.

Step 4: Automate backups with cron

A backup you have to run manually will eventually get skipped. Drop this into /etc/cron.d/glpi-backup to run nightly at 2am:

0 2 * * * root /usr/local/bin/glpi-backup.sh

A minimal glpi-backup.sh:

#!/bin/bash
set -euo pipefail
DATE=$(date +%F)
DEST=/backup
tar -czf "$DEST/glpi_files_$DATE.tar.gz" -C /var/www glpi
mysqldump --defaults-file=/root/.my.cnf --single-transaction --quick --routines glpi_db \
  | gzip > "$DEST/glpi_db_$DATE.sql.gz"
find "$DEST" -name "glpi_*" -mtime +30 -delete

The last line keeps 30 days of backups and deletes older ones. Adjust the retention to your needs.

Step 5: Store backups off-site

A backup sitting on the same server as the database doesn't help when the server fails. Copy backups to a separate location — S3, Backblaze B2, another data centre, or an on-prem NAS on a different host. rclone handles most cloud targets with one command:

rclone copy /backup remote:glpi-backup --include "glpi_*"

Test your restores

An untested backup is a hope, not a restore procedure. At least once a quarter, restore to a staging environment: extract the files, import the SQL dump into an empty database, point a test GLPI instance at it, and verify you can log in and see tickets. You'll catch broken file permissions, corrupt dumps, and incompatible MariaDB versions before they matter.