Why GLPI database growth happens and when a history purge helps
A GLPI database that keeps growing eventually makes backups longer, slows upgrades and turns routine maintenance into a wait. Before you change anything, confirm which tables are driving the growth. In most self-hosted instances the largest contributors are the event log table (glpi_logs), the history of changes made to software and user records, queued notifications, and inventory records that accumulate each time an agent reports. Each of these grows for a different reason, so each needs a different retention decision. A history purge is the GLPI mechanism that deletes rows older than a retention period you set, and it only helps for data you have decided you no longer need to keep.
That is why a history purge is a governance decision as well as a technical one. Someone must decide how long audit trails, change history and software installation records need to be available for your internal reviews, your incident investigations and any compliance evidence you rely on. Those answers belong to security, compliance and service owners, not only to the people who run the server. Purging history that a review later needs cannot be undone from the same database, so the retention rule should be written down and approved before the first delete runs. Check the retention settings and the scheduled purge action in your own GLPI version, since the names, locations and defaults have changed between releases. The GLPI user documentation covers authentication rather than purging, so use the documentation for your exact release and the GLPI project site for version-specific guidance.
A purge helps most when the growth is in rows that have no ongoing value, such as old log entries beyond your audit window. It helps less when the database is large because of live assets, tickets and attachments, because purging history will not shrink those. Start by measuring table sizes and row counts in the GLPI database, then compare them with the retention periods your organization has approved. If the numbers show the growth is mostly history, plan the purge as a staged change with a verified backup and a test restore, and agree who signs off on the retention rule.
Log retention options per entry type and when each fits
This table compares the main history types that accumulate in a GLPI database, what shortening each one removes, who relies on that history, and the risk of cutting it too short. Read each row before changing a retention value, and confirm the exact labels and available entry types in the administration screens of your own GLPI release, since they vary by version.
| Entry type | What a shorter retention removes | Who needs it and why | Risk of shortening |
|---|---|---|---|
| Item change history (logs of field edits on assets, tickets and other items) | Older records of who changed which field and the old and new values | Asset managers and auditors tracing when a serial number, owner or status changed; service desk leads reviewing ticket edits | Losing the evidence needed to explain an asset record at a past date during an audit or dispute |
| Software installation and removal history | Older entries recording software added or removed on inventoried computers | License compliance reviewers and security teams checking when a product appeared on an endpoint | Gaps in license true-up or incident timelines if a vulnerable package was present during a past window |
| User history and account changes | Older records of profile, group, entity or authentication-related changes on user accounts | Access reviewers confirming who held which rights at a given time; security staff investigating privilege changes | Weakens evidence for access certification and insider investigations |
| Login and session records | Older records of sign-in attempts and session activity | Security operations for brute-force or account takeover checks; help desk when troubleshooting SSO or LDAP sign-in failures | Reduced ability to detect repeated failures or reconstruct a compromise window |
| Notification and queue records | Older records of sent or queued notification messages | Support staff confirming a ticket email was sent; administrators diagnosing mail delivery problems | Harder to prove that a notice reached a requester, which matters for SLA disputes |
| Automatic action and task execution logs | Older records of scheduled action runs and their outcomes | Administrators diagnosing cron or automatic action failures after an incident | Troubleshooting becomes guesswork if the failure happened before the retained window |
Why staged purges beat one large delete
A single large purge that removes years of history in one run is the fastest way to turn a bloated glpi_logs table into a production incident. Deleting millions of rows in one transaction or one long batch can hold locks on the table for an extended period, grow the database's transaction or redo logs well beyond normal levels, and push replication lag up if the instance has replicas. When such a run fails halfway through, the error is often a timeout or a disk-full condition with no clear record of which entry types were already removed. That makes it hard to tell whether the database is consistent, what still needs cleaning, and whether the next attempt is safe.
A staged approach keeps each step small enough to observe. Start with the entry type you are least sensitive to losing, such as low-value interface or cache-related history, and run it inside an agreed maintenance window. Record row counts for the affected tables and the database size before the run, then again afterwards, and note how long the action took. Only when the first stage has completed cleanly should you widen the scope to software history or user history, which carry more audit and support value. Each stage gives you a measured baseline for the next one, so the time and storage it needs can be estimated from evidence rather than guessed.
Every stage needs a rollback plan and a backup you have already tested. Confirm with your own change process which backup set you will restore from, verify that a restore of the database and the config directory works in a separate environment, and record the GLPI version and the retention settings in force before you start. Decide in advance what counts as a stop condition, such as lock waits that keep growing or free disk space falling below the level your team has agreed. Retention changes for the history you are purging should also be documented, so that auditors and support staff can see what was removed, when, and under which policy.
Software history and user history need different purge plans
Software and inventory history records how installed applications, operating systems and hardware changed on each asset over time. Licensing and asset teams use it to reconstruct what was installed on a given date, which matters for license reviews, vendor true-up discussions and proving that an asset was decommissioned. Because inventory agents report on a schedule, this history grows steadily with the number of managed devices, and it is often the largest contributor to table size on an inventory-heavy instance.
- Who signs off: usually the software asset management lead, with the finance or procurement owner of license contracts consulted when the retention period is set.
- Purpose check: confirm whether the history backs license position statements, contract disputes or only day-to-day reporting, since each use implies a different window.
- Current versus historical data: ask whether the current inventory state is kept separately from change history, so a purge does not remove what the asset record shows today.
- Staging: plan software history as its own purge stage, with a verified backup and a sample reconciliation of license counts before and after.
- Vendor contracts: check whether any contract or audit clause requires you to show installation records going back a fixed period.
Before purging, confirm the retention period in writing with the license owner and record who approved it.
User and account history covers login-related events, profile and entity changes, group membership changes and actions taken on user records. Security and access review teams rely on it to answer who had access to what at a given time, to investigate a suspicious sign-in, and to show that leavers lost access when they should have. This data is more sensitive than inventory history because it contains personal information about staff, so retention decisions also involve privacy and HR.
- Who signs off: the information security or identity owner, with HR, the data protection officer or legal counsel consulted on personal data retention.
- Access review needs: ask which periodic access reviews depend on historical records and how far back they look.
- Investigation windows: confirm how long the security team expects to investigate incidents, since a purge that removes login history can end an investigation early.
- Identity source: check whether authentication events are also kept in the directory or SSO provider, which may change how much GLPI needs to retain.
- Data minimization: ask whether any personal fields in history can be pseudonymized or removed before the record is purged, instead of deleting the whole entry.
Before purging, confirm the period with security and HR and document the legal basis for keeping the data at all.
General logs cover the wider set of entries GLPI writes for item changes and system events across ticket, asset and configuration objects. Service desk leads and auditors use them to investigate incidents, trace who changed a field and reconstruct the sequence of events on a record. This family is usually the broadest, which is why its retention is often set as a default for everything, and that default is the point where teams most often apply a single rule without checking each entry type.
- Who signs off: the ITSM process owner for service records, with the internal audit function consulted where change traceability is a control.
- Entry types: list the entry types that actually generate volume on your instance before choosing any retention, since a few types often dominate the table.
- Incident reviews: ask how long post-incident reviews or problem records may refer back to older item changes.
- Change control evidence: confirm whether change records are kept in GLPI or in a separate change system, which affects how much log history is needed.
- Test first: run the purge on a restored copy of the database and compare record counts per entry type before applying it to production.
Before purging, confirm per entry type which teams need the history and where its retention is documented.
Setting up a history purge with checks at each stage
This sequence moves a GLPI history purge from a documented decision to a production change with a restore point, a measured baseline and a verified test run. Each stage ends with a check that must pass before the next one begins, so the production run is a repeat of a rehearsal rather than a first attempt.
Take and verify a full backup
Before any purge, back up the GLPI database, the files directory and the config directory, including the glpi.key and glpicrypt.key files. Whoever runs the change owns this step, and it should follow the backup procedure your team already uses for GLPI. The check that closes it is a test restore of the database dump into a separate server, followed by a login and a ticket lookup. A backup that has not been restored is not yet a restore point.
Record table sizes and row counts
Capture the size of each large table in the GLPI database, with particular attention to glpi_logs, and the row count for each one. Keep the query output, the GLPI version and the date with the change record. This baseline is what you compare against after the purge to show what was removed and how much disk space was actually returned. Confirm the numbers come from the live database and not from an estimate in the administration console.
Document retention decisions per entry type
Write down how long each category of history must be kept, such as ticket-related logs, software installation history, user login history and notification records. Name the owner who approved each period, the audit or operational reason behind it, and any records your compliance or legal team needs to keep longer. Check the decisions against your asset inventory evidence requirements before configuring anything. The record is complete when every entry type in the baseline has an approved period or an explicit decision to keep it.
Configure retention in GLPI
Set the retention values in GLPI for each entry type as documented in the decisions. Change one category at a time where possible, so that a later result can be traced to a single setting. Save the configuration, then export or screenshot the final values and attach them to the change record. The check is a second reviewer comparing the saved values against the approved document, field by field.
Run PurgeLogs on a test copy
Restore the verified backup into a staging environment that matches production's GLPI version, plugins and database engine as closely as possible. Run the PurgeLogs automatic action there, either from the administration console or through the command line, and confirm it completes without errors in the logs. Record the row counts and table sizes after the run and compare them with the baseline. Stop if the counts do not match what the retention decisions predict.
Confirm application behavior after the test run
On the staging copy, check the functions that depend on history: open a sample of tickets and their followups, check software and asset histories for retained items, confirm user login and profile pages load, and test the notification queue. Check that plugins still start after the purge. Ask the business owner of each retained data type to sign off the sample. The stage passes only when every item on the checklist works as expected and no error appears in the GLPI logs.
Run the purge in production and record results
Schedule the production run in a maintenance window that your change process allows, and put GLPI into maintenance mode before the purge starts. Repeat the exact steps that succeeded in staging, in the same order. Afterwards, repeat the size and row count queries, take a fresh backup, and attach the before and after figures, the staging sign-off and the GLPI version to the change record. The change is closed when the production results match the staging results and the post-change checks pass.
Reclaiming disk after rows are deleted
Deleting rows from a GLPI database usually does not shrink the files on disk right away. The database engine marks the freed space inside its data files for reuse by future inserts, so the purge can complete while the storage volume still looks full. Before a purge, record the current size of the glpi_logs table and the database data directory, then compare both after the purge and after GLPI has run for several days. Growth that resumes at the old rate is normal reuse, not evidence that the purge failed. The DBA should also confirm which storage engine each large table uses, because the options for returning space depend on it.
Three options are worth evaluating with your DBA. The first is to leave the freed space alone and let the engine reuse it, which costs nothing and carries no downtime, but leaves the file size unchanged. The second is scheduled maintenance, such as an optimize or defragmentation run during a quiet window, which can return space to the operating system but still locks the table for the duration and needs free disk headroom to write a new copy of the data. The third is a full table rebuild, which gives the most compact result but holds locks longer, roughly doubles the space needed for the table while it runs, and should be preceded by a verified backup. Ask your DBA to estimate the lock behavior and free space for your table sizes on a restored copy before choosing.
Heavier schema work, such as engine conversions, column changes or index work on very large tables, is a separate job with its own risks and is covered in the sibling topic on using Percona Toolkit on large GLPI databases. Keep reclaiming disk and schema migration apart in your change plan so that a space recovery run is not combined with structural changes. Confirm with your DBA which maintenance windows, backup point and monitoring alerts apply before any table rebuild starts.
Security and audit risks of deleting history
A purge is permanent, and the history it removes can be the evidence an investigation, auditor or access review later asks for. The cards below cover the decisions to close and the checks to run before the first delete, so that the database shrinks only for data your retention rules say to drop.
Deleting evidence for investigations
Log rows in glpi_logs record who changed a ticket, asset or user and when. If a security incident or HR matter surfaces after a purge, those rows may be gone for the period in question. Before purging, confirm with security and legal whether any open or recent investigation depends on the entry types you plan to remove, and hold those types or date ranges until the matter closes.
Removing change history auditors expect
Auditors and access reviewers often sample change records for assets, user rights and profile assignments over a set period. A purge that trims those entry types shortens the window they can test. Ask the compliance owner which audit periods must remain queryable in GLPI and set retention per entry type to cover them, not to the minimum the database would tolerate.
Purging before retention is approved
Retention periods are a policy decision, and purging ahead of sign-off turns an administrator's judgment into a permanent deletion. Confirm in writing which entry types, periods and owners have been approved, record the approval reference, and make the first purge a dry run on a restored copy so the rows affected are known before production is touched.
Keeping purged data in backups
A purge removes rows from the live database, but existing dumps, snapshots and replicas still hold them. If the policy says data must be deleted after a set period, the backup retention schedule has to match, or the organization keeps data it has agreed to remove. Confirm how long backups are kept, who can restore them, and whether restored copies are subject to the same purge rules.
Exposing the purge account rights
Purging needs write and delete rights on the GLPI tables, which is more than the application account normally holds. Running the purge with a shared or over-privileged database account lets anyone with that credential alter or erase records. Confirm the minimum privileges required for the purge, use a dedicated account that exists only for maintenance, store its credentials in your secrets system, and remove the grant when the work is done.
Losing the record of the purge
Once rows are deleted, GLPI cannot show who triggered the purge, when it ran or which retention values were in effect. Record the operator, the change ticket, the retention settings before and after, row counts from a pre-purge query, and the database backup taken just before. Keep that record outside the database that was purged so the purge itself can be audited later.
Common questions about GLPI database growth and history purge
How much does a GLPI history purge cost?
The cost is set by the written scope, not by a list price, and DeployOpen does not publish one. The main components are an assessment of which tables are large and why, a retention policy that the business approves, the purge runs themselves, verification that the application still behaves correctly, and the disk reclaim step. Costs rise when the database is large, when history must be kept for audit reasons, when several entry types need separate rules, or when the team needs a runbook for future purges. Costs fall when backups are current, the instance is a single standard install, and the retention decisions are already written down. Ask any provider for a fixed-scope quote that lists each of these components separately, and state whether one-time work and any recurring retention job are priced apart.
How long does a GLPI history purge take?
Duration depends on how much history must be removed, how large the affected tables are, how much of the work can run outside business hours, and how many entry types need their own retention rules. Staged purges of software and user history usually take longer than a single PurgeLogs pass because each stage needs a check before the next one starts. Disk reclaim can also take time, and it depends on the database engine and the storage layout. No duration is given here because none is supplied for this topic. Ask the provider for a timeline tied to your table sizes, your maintenance window and your approval steps, and confirm which of those steps the provider will perform and which your team must perform.
What must our team provide before a history purge starts?
The team needs to provide four things: verified backup access, a written retention policy, a maintenance window, and database rights that allow the purge and any table maintenance. A tested backup and restore path is required before any delete runs, so confirm who holds the database dump and who can restore it. The retention policy should name each log type, how long it is kept, and who approved it. The maintenance window should allow users to be told that GLPI may be slow or unavailable. The database account needs the privileges to delete rows and, where relevant, to run schema or table operations. Agree these items in the statement of work so the start date does not slip.
Can an internal GLPI administrator run a history purge alone?
An internal administrator with database and GLPI console experience can often run a simple purge alone, especially on a standard install with current backups. The work becomes harder when the database is large, when history feeds audit or contract records, or when the purge involves software and user history that other reports depend on. In those cases the risks are mistaken deletions and long table locks, not the command itself. Before deciding, ask whether your team can restore a backup into a test environment, read the GLPI log retention settings, and document the result. A partner can supply an independent review of the plan, a staged runbook and a second pair of hands during the run, which is a different service from running the purge for you.
How should we decide what history to delete?
Decide by entry type and by the business use of each record, not by table size alone. For each log type, record who uses it, which reports or audits depend on it, and what legal or contractual retention applies. Software and user history often serve different purposes from ticket or notification logs, so they should be decided separately. Test the proposed rule on a restored copy first and check that the dashboards, reports and inventory views still return the results people expect. Keep a short written record of each decision, including the approver. Your compliance or records owner should confirm retention periods, because the technical team can only confirm what the software can delete.
Does purging GLPI history affect audit evidence?
It can. GLPI log tables may hold the change and access history that auditors sample when they test inventory, access or change controls. Before purging, identify which records are evidence for controls in scope, and export or archive what must be kept under your retention policy. Purging a table that the assessor expects to see for the full period can leave a gap that is hard to explain later. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors decide what is sufficient. Ask your auditor which records they need before any purge is scheduled.
How is a GLPI history purge quoted?
DeployOpen agrees most engagements as fixed-scope work, with the scope, deliverables and timelines written down before work starts, and it does not publish a price list. A useful quote should list the current GLPI version and database engine, the entry types in scope, the retention rules to apply, the backup and restore verification, the staged purge plan, the disk reclaim step, and the handover documents. It should also state which items are one-time and which recurring, such as a scheduled retention job or a support retainer. Ask for the assumptions behind the quote, the items the client must provide, and what triggers a change request. Compare providers on the written scope rather than on headline figures.
How DeployOpen scopes and delivers a GLPI history purge
DeployOpen approaches GLPI database growth as a planned change to your own instance: first measuring which log tables are large and why, then agreeing retention rules in writing, then running purges in stages with verified backups. Each step is documented so your team can repeat it and explain it to auditors.
How we scope
- Review table sizes, log volume and current retention settings in your GLPI instance before proposing any purge.
- Agree retention periods per log entry type and which history tables are in or out of the purge.
- Write the scope, deliverables and timeline down before work starts, since engagements are fixed-scope.
- Confirm the backup, maintenance window and rollback steps with your database and operations owners.
How we build
- Configure the PurgeLogs settings and automatic action for the retention rules you approved.
- Run software and user history purges in stages, checking row counts and application behavior after each stage.
- Test the full sequence on a restored copy of your database before touching production.
- Plan disk reclamation separately so space is returned to the operating system only after verification.
How we hand over
- Document the retention matrix, the purge schedule and the exact console commands your team will run.
- Record before and after measurements so future growth can be compared against a known baseline.
- Walk your administrators through restore testing and what to check if a purge removes data unexpectedly.
- Deliver the runbook in your own repository or document store, under your control.
How we support
- Ongoing support, upgrades and periodic growth reviews are available as a retainer after handover.
- Support can cover re-checking retention rules after GLPI version upgrades or plugin changes.
- Ask any provider to confirm in writing how upgrades to GLPI 11 or 12 affect your purge settings and schedule.
