Why a GLPI backup is more than a database dump
A self-hosted GLPI holds tickets, asset records, contracts and credentials for other systems, and those records live in two places: the database and the files directory. A database dump alone is not a recoverable backup. Files such as uploaded documents and attachments sit outside the database, and the encryption keys that GLPI uses to protect stored secrets sit in the config directory. Restore the database without the matching files and keys, and you may get an instance that starts but cannot show attachments or decrypt stored passwords.
GLPI's update procedure, documented in the installation guide, names the minimum set: back up the database, back up the files, and back up the config directory, which includes glpi.key and glpicrypt.key. Those files are the ones teams most often overlook, because they are not in the database and are not part of the application code you replace during an upgrade. Treat this set as mandatory before every update, including minor releases such as moving between 11.0 point versions, and before any change to the web server, PHP or database engine. Ask your team to confirm which other paths and settings your install relies on, such as custom plugin directories or a relocated files path, since those vary by layout.
The backup is only proven when you restore it. Plan a test restore into a separate host or container with the same PHP and database versions, then run php bin/console db:update against the restored copy and confirm that users can sign in, tickets open and attachments download. Keep the matching set of files, database and keys together with the same timestamp, because mixing a database from one day with keys from another causes the same failures a missing key does. Ask whoever owns your backup tooling to confirm retention, encryption at rest and off-site copies, since those decisions sit outside GLPI itself.
What a complete GLPI backup contains
A GLPI backup is only useful if it captures everything the application needs to run and decrypt its own data. The database holds the business records, the files directory holds attachments and generated content, and the config directory holds the keys that make stored secrets readable. The web server and PHP settings complete the picture because a restored instance must serve the same way it did before.
Database dump
The MySQL or MariaDB database holds tickets, assets, users, rules and most configuration. Take a consistent dump with the database engine's own tool while GLPI is in maintenance mode or after a quiet period, so tables do not change mid-dump. Record the database name, character set and the GLPI version alongside the file, because a dump restored into a different schema state will need php bin/console db:update before it runs.
Files directory without cache
The files directory stores document attachments, inventory data and other content that the database references by path. Copy it with the cache and session folders excluded, since those are regenerated and can be large or stale after a restore. Confirm which subfolders your install generates, because the list depends on the features you use, and check that the restored tree keeps the same ownership so the web server can write to it.
Config directory and keys
The config directory holds the database connection settings and the keys in glpi.key and glpicrypt.key. Back it up as its own item, with restricted access, because the backup contains secrets. Store it separately from the database dump so a leaked dump does not expose the keys.
Why glpicrypt.key matters
GLPI uses glpicrypt.key to encrypt certain stored values, such as credentials for external connections. If this key is lost, the encrypted values in a restored database cannot be decrypted, and the affected integrations must be reconfigured by hand. Treat the key as part of the database backup, not an optional extra, and test that a restored instance can still use the stored credentials.
Web server and PHP configuration
The virtual host, URL rewriting rules, PHP version and extensions, and php.ini limits determine whether GLPI starts and behaves as before. The document root must point to GLPI's public directory, and a restore onto a server without the same rewrite rules will fail in confusing ways. Save these files with the backup and record the PHP version, because the minimum PHP version changes between GLPI releases.
Restore test checklist
A backup that has never been restored is unverified. Before each upgrade, restore the set into a separate host or container, run php bin/console db:update if the version differs, and confirm logins, attachments, notifications and a sample integration. Ask your operations team to record how long the restore took, since that figure sets the realistic rollback window for your change plan.
Backup methods and when each fits
This table compares the three ways to back up a self-hosted GLPI instance: logical database dumps, physical or filesystem copies, and VM or volume snapshots taken with the database quiesced. Read each row against your own database engine, hosting platform and restore expectations, then choose the combination that covers the database, the files directory and the config keys together. Whichever method you pick, a full GLPI backup still needs the key files, and only a test restore shows that it works.
| Method | Consistency | Restore speed and size | What it misses |
|---|---|---|---|
| Logical dump with mysqldump or mariadb-dump | Consistent when run with a single-transaction option on InnoDB tables and no schema changes during the run. Confirm the options against your database version. | Restore replays SQL, so it is usually the slowest path for large tables. Dump files are often smaller than raw data directories, but compression ratios vary. Measure both in your environment. | Does not include the files directory, the config directory or glpi.key and glpicrypt.key. Those must be copied separately. |
| Physical or filesystem copy of the database directory | Consistent only if the database is stopped or flushed and locked before the copy. A live copy of data files is unsafe. | Restore is often faster than replaying SQL, but it needs the same engine and version. Size tracks the full data directory, including free space and logs. | Does not capture a point-in-time state unless logs are kept. Restoring to a different major database version is a separate task. |
| VM or volume snapshot with the database quiesced | Consistent when the database is flushed and paused before the snapshot. Confirm that your hypervisor or storage tool supports application-consistent snapshots. | Usually the fastest whole-system restore. Snapshot size depends on change rate and retention, so measure it during a normal week and during an upgrade window. | Captures everything on the volume, but restores are coarse. Single-file recovery may be slow, and snapshots on the same storage are not an off-site copy. |
| Files directory copy excluding cache and session folders | Consistent when GLPI is in maintenance mode or the copy happens during a quiet period, because uploaded documents and configuration can change while copying. | Size depends on attached documents and any plugin data. Excluding cache and session folders keeps the backup smaller, but confirm the exact folders in your version's documentation. | Does not include the database. Document attachments and the database must be restored to the same point in time. |
| Config keys and configuration files | Consistent only when copied with the rest of the backup set. Keys must match the database they were used with. | Very small. Restoring the wrong key set can make encrypted fields unreadable, so label the copies clearly. | Does not contain data. Store keys separately from the data copy, with access restricted to the people who run the restore. |
| Test restore into an isolated environment | Proves that the chosen methods produce a working instance together, which no single method can show alone. | Duration depends on data volume and hardware. Time a full restore in a non-production environment and record it before any upgrade. | Does not prove that backups are complete for systems outside GLPI, such as mail relays or LDAP configuration that GLPI depends on. |
How to set up and run a GLPI backup
This sequence captures a GLPI instance at one consistent point in time: the database, the files directory, and the config directory with its key files, plus a record of the versions in use. Each step ends with a check, so the backup set is known to be complete before anything changes on the live system.
Confirm the backup window and freeze writes
The administrator who owns GLPI chooses a quiet period and tells users that tickets and asset edits may be paused. Enable maintenance mode from the GLPI administration console or the command line so that no new writes land during the copy. Also confirm that no automatic actions are running, since they write to the database in the background. You know this step is done when a test login by a non-administrator shows the maintenance notice and a page reload confirms that the instance is no longer accepting changes.
Dump the database with consistent options
The database administrator runs a logical dump of the GLPI database using MySQL or MariaDB tooling, with options that produce a single consistent snapshot, such as a single-transaction dump for InnoDB tables. Store the dump in a dated file and keep the credentials out of shell history and process lists. Check the output by confirming the file is not empty, that it ends with the expected completion marker, and that a restore into a scratch database (covered in the test restore) reports no errors. Record the database server version alongside the file.
Copy the files directory without cache and sessions
The web administrator archives the GLPI files directory, which holds uploaded documents, generated files and attachments, and excludes the cache and session folders. Cache and session content is rebuilt by GLPI and can be large or stale, so leaving it out keeps the archive smaller without losing business data. Confirm the exclusions in the archive listing and compare the file count against the live directory, accounting for the excluded folders. Preserve ownership and permissions so the web server user can read the restored files.
Copy the config directory and key files
The administrator archives the GLPI config directory separately, because it holds the database connection settings and the key files glpi.key and glpicrypt.key. Without these keys, encrypted values stored in the database, such as credentials for external services, cannot be read after a restore, so this copy is as important as the database. Treat the archive as sensitive and restrict who can read it. Verify by listing the archive and confirming that both key files and the database configuration are present and non-empty.
Store copies outside the GLPI host
The team transfers the database dump, the files archive and the config archive to storage that is separate from the GLPI server, such as another system or object storage in the same controlled environment. Encrypt the copies at rest and set retention according to your own policy. Confirm the transfer by comparing checksums of the source and destination files, then confirm that the destination can be read by the account that will perform a restore. Storing the only copy on the GLPI host means a host failure removes the backup too.
Record the GLPI, PHP and database versions
The administrator writes a short manifest beside the backup set that records the GLPI version, the PHP version, the database server version, the web server and the list of active plugins with their versions. A restore must run on a compatible stack, and the GLPI installation docs describe the supported PHP and database versions for each release line, so the manifest tells the restore team which environment to rebuild. Check the manifest against the running system and store it with the archives. The check is complete when the recorded GLPI version matches the output of the version command.
Return GLPI to service and verify the backup set
Disable maintenance mode and confirm that users can sign in and that the ticket and asset pages load. Then run the full checksum and archive-listing checks against the stored copies, and perform a test restore into a separate environment before any upgrade or change, following the restore steps in this guide. Log the backup time, the operator and the verification results in your change or operations record. The backup is considered usable only after a restore has been tested successfully, not when the files are written.
How to prove a GLPI restore works before an upgrade
The GLPI update procedure starts with a backup of the database, the files and the config directory, but a backup is only proven once it restores cleanly on another host. Before you run php bin/console db:update against production, restore the database dump and files onto a separate VM or host that runs the same GLPI version you are on now, with the same PHP and MariaDB or MySQL versions. Confirm that the glpi.key and glpicrypt.key files came across with the files directory, because without them the encrypted fields in the restored database cannot be read. Ask your team to confirm where these keys are stored and who can retrieve them during an incident, since a restore that lacks them is a failed restore even if the dump loads.
Once the copy is running, work through a short acceptance checklist. Sign in with a local account and with your directory account, open a ticket with an attachment and confirm the file opens, and open an asset record and an entry that stores an encrypted value, such as a stored credential or an authentication setting. Then confirm cron-driven behavior: run the automatic actions from the command line for one cycle and check that mail collection and notifications behave as they do on production, while outbound mail is redirected to a test address so the copy does not email real users. Record the results so the sign-off has evidence behind it.
Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so the test must include every plugin you run. On the copy, list the active plugins before the upgrade, run the planned upgrade, and then reactivate each plugin one at a time, checking its pages, its custom fields and any scheduled actions it registers. Confirm the plugin vendor supports the target GLPI version before you start, because a plugin that will not reactivate can stall the upgrade. Use the results to decide whether the production window needs extra time for plugin work and whether any plugin must be replaced before the upgrade proceeds.
Protecting backup data and keys
A GLPI backup is a copy of the database, the files directory and the key files, so it holds nearly everything an attacker would want. The cards below cover the risks that connect those parts and the controls to confirm before the first backup runs.
Encrypt backups at rest
Database dumps contain user records, ticket content, asset and contract data, and stored credentials for integrations. Encrypt every archive and the copies sent off site before they leave the backup host. Confirm which tool and key management your team uses, and test that an archive can be decrypted on a clean machine before you depend on it.
Protect glpi.key and glpicrypt.key
The config keys stored with GLPI decrypt the values GLPI stores encrypted in its database. A database dump without these keys may restore, yet encrypted fields will not read correctly. Keep the keys in a separate secret store with its own access list, not beside the dump in the same bucket.
Handle session data as sensitive
GLPI 12.0.0 added a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Session records can hold live access that outlives a password change, so treat any session table or files directory copy as sensitive. Decide whether sessions are excluded from backups, and confirm that with your security owner.
Restrict who can read backups
Backups are often readable by more people than the production system, including storage administrators and backup operators. Limit read access to a named group, require separate credentials for restore, and remove access for people who leave the platform team. Review the access list on a schedule that your access policy sets.
Separate key storage from data copies
Storing the keys and the data in one location means one compromise exposes both. Place the key copy in a different system and different account from the data copy. Document where each copy lives and who can retrieve it, so a restore can proceed during an incident without relying on one person's workstation.
Log every restore action
A restore can overwrite live tickets, assets and user accounts, so it is a privileged change. Record who started the restore, which archive and key version were used, the target environment, and the time it finished. Keep these records with your change log. Confirm the retention period for these records with your compliance owner.
Questions teams ask about GLPI backups
How much effort does a GLPI backup and test restore take?
The effort depends mainly on database size, the size of the files directory, how many plugins are installed and how much of the restore is rehearsed in a separate environment. A backup job on a small instance is short to script, but a test restore takes longer because someone must rebuild the application, load the database and files, and check that logins, tickets, assets and attachments behave correctly. The main cost components are engineering time to script and document the backup, the restore rehearsal itself, and the storage and retention design. Ask any provider to break the quote into backup setup, restore test, documentation and handover, and to state which items recur, such as periodic restore tests before each upgrade.
Can our internal team back up and restore GLPI without a partner?
Yes, if the team can run database dumps, copy the files directory and manage the configuration keys, and has a spare environment for restore tests. The work becomes harder when the team lacks a documented procedure, has never restored a GLPI instance, or runs custom plugins whose data lives outside the standard tables. Engineers should confirm they know where the glpi.key and glpicrypt.key files sit, because a restore without them can leave encrypted data unreadable. Teams often hand the restore rehearsal to a partner once, then run the documented routine themselves. Ask a partner to hand over runbooks that your staff can follow without the author present.
What does a backup project need from our team?
A backup project needs read and write access to the GLPI application server, the database host and the file storage used for the files directory, plus a named contact who approves change windows. Teams should also provide a secondary server or virtual machine for restore tests, because restoring over production is not a test. Storage needs include space for each full copy and the retention period you choose, and secure, access-controlled locations for the configuration keys. Ask the provider to list every access account, host and storage target it expects, and to confirm whether backups need a maintenance window or can run while users are active.
How often should we back up a self-hosted GLPI instance?
The frequency should follow how much data you can afford to lose and how often the instance changes. Tickets, assets and user records change throughout the day, so most teams set a database dump schedule that matches their tolerance for lost work, and copy the files directory on a schedule that reflects new attachments and documents. Always take a fresh, complete backup before any GLPI update, because the update procedure replaces application files and runs database updates. Keep the schedule in your runbook and confirm retention with your compliance owner, since some records may need to be kept for a set period.
Do GLPI's built-in features replace an external backup tool?
No. GLPI manages its own data and can run scheduled automatic actions, but it does not provide a complete, off-host backup of the database, the files directory and the configuration keys together. An external process should dump the database, archive the files directory minus cache and session folders, and store copies away from the server, so a failed host does not take the backups with it. Built-in history purge and log retention reduce database growth, but they delete data rather than protect it, so they should not be treated as backup. Confirm the exact behavior of your GLPI version in its documentation before relying on any built-in feature for recovery.
Why must the configuration keys be included in the backup?
GLPI uses the glpi.key and glpicrypt.key files in its config directory to protect sensitive values, so a database dump alone may not restore a working instance. Without these keys, encrypted fields such as stored credentials can fail to decrypt after a restore. Store the keys separately from the database dump, restrict who can read them, and record where each copy lives. Test this during the restore rehearsal by confirming that a restored instance can still use any integration that stores secrets.
What should a quote for a GLPI backup and restore include?
A useful quote lists each deliverable: backup scripts or jobs, the list of backed-up items, the exclusion rules for cache and session folders, retention settings, storage locations, a restore procedure, and at least one documented test restore into a separate environment. It should also state what the provider needs from you, the change windows assumed, the environments in scope, and whether plugin data and custom directories are covered. Ask which work is one-time and which recurs, such as repeated restore tests before each upgrade, and whether support for future restores is included.
Limits to confirm in your environment
A GLPI backup is only as good as the assumptions behind it. The version support, dump consistency and volume layout below decide whether a dump taken today restores cleanly on the target platform. Confirm each one against the vendor docs and with a test restore in your own environment.
Database versions for GLPI 11
The GLPI 11 installation docs list MySQL 8.0 or MariaDB 10.6 with PHP 8.2 or later, and state that only MySQL and MariaDB are supported. Confirm the database engine and version you run against that page before you choose a dump tool. Restore into the same major engine and version family you backed up from, and record both versions with each backup set.
Requirements for GLPI 12
The GLPI README on the main branch lists PHP 8.3 or later and MariaDB 10.11 or later, or MySQL 8.0 or later. These requirements differ from the GLPI 11 docs, so a backup taken on an older database version may not restore onto a GLPI 12 target without a database upgrade. Check the README and release notes for the exact version you plan to run before scheduling the upgrade.
Dump consistency under load
A dump taken while technicians create tickets, while automatic actions run, or while the notification queue is active can capture rows that reference each other at different points in time. Ask your database team whether your engine supports a single-transaction dump for InnoDB tables, and whether you can pause or limit scheduled actions during the window. Verify consistency by restoring a dump taken during normal load and checking row counts on the busiest tables.
Docker volume layout
Containerized GLPI keeps the application, the files directory and the configuration in separate locations that depend on how you mount them. Confirm which host paths or named volumes hold the files directory and the config directory, and whether the database runs in a separate container with its own volume. A backup that captures only the container image or only one volume will not restore a working instance.
Encryption key location
The config directory holds glpi.key and glpicrypt.key, which GLPI needs to read encrypted fields in the database. Confirm where these files live in your deployment and that your backup captures them alongside the database dump. Store them separately from the dump under the same access controls as the database, because a dump without its keys cannot decrypt those fields.
Plugin state after restore
Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Confirm which plugins you run and their compatibility with the target version before the upgrade, and list them in your restore runbook. Expect a restored instance to need plugin review even when the database and files restore cleanly.
Running backups as an ongoing operation
A GLPI backup only protects you if it keeps running and keeps working. Treat the dump, the files copy and the config keys as one recurring job with a schedule, a retention rule and a named owner. Set retention so that you can go back to a point before a bad change, a corrupted import or a failed plugin update, and keep the copies on storage separate from the GLPI host. Confirm with your storage team how many generations your policy requires and where off-host copies are kept, since those decisions depend on your environment rather than on a GLPI default.
Schedule backups around the work GLPI does in the background. Automatic actions such as mail collection, notification sending and SLA calculation can write to the database while a dump runs, and maintenance mode changes how users reach the instance during a copy. Check how your automatic actions are scheduled before you fix the backup window, and use the sibling topics on running automatic actions from cron and on GLPI maintenance mode and console administration to decide when to pause or quiesce the instance. Record the chosen window and any maintenance steps in the runbook so that the backup job and the GLPI jobs do not collide.
Re-run a full backup before every GLPI version change, and schedule restore drills on a regular cadence. A drill restores the latest database dump and files copy into a separate host, starts GLPI against it, and confirms that logins, plugin states, attachments and the glpi.key and glpicrypt.key files all work. Plugins are suspended after a new version is detected, so a restored instance also shows whether your plugin list is still complete. Agree with your team how often drills run and who signs off the result, and keep the drill log with the change records. A backup that has never been restored is an untested assumption.
How DeployOpen works on this
DeployOpen plans and builds GLPI backup and restore inside your own infrastructure, covering the database, the files directory, and the config keys that GLPI needs to read its stored secrets. Each engagement ends with a restore you have tested yourself, not just a backup job that reports success.
How we scope
- Inventory where the GLPI database, files directory and config keys live, and who can read each one.
- Agree which files directory folders are excluded, such as cache and session paths, and record the reasoning.
- Set retention, backup frequency and storage location for each copy in the written, fixed-scope agreement before work starts.
How we build
- Configure scheduled database dumps and file archives that run on your backup platform, with encryption and access control.
- Store copies of glpi.key and glpicrypt.key separately from the data they protect, with restricted access.
- Run a full test restore into a separate environment and record the steps, timings and any gaps found.
How we hand over
- Document the backup job definitions, restore runbook and a pre-upgrade checklist that includes a test restore.
- Walk your operators through a restore of the database and files so they can repeat it without us.
- Confirm with you which checks, alerts and evidence your team needs to show that backups completed and restored.
How we support
- Ongoing support, upgrades and testing can be taken on as a retainer after handover.
- Re-run the test restore when GLPI is upgraded, when plugins change, or when the database platform changes.
- Review backup job logs and storage capacity with your team on the cadence agreed in the retainer.
