Recovery Runbook
Dolibarr Backup and Recovery Runbook
Runbook for consistent database and document backups, restore tests, RPO, RTO, module compatibility, and acceptance.
Core answer
A reliable Dolibarr backup includes the database, document directory, configuration, and custom modules in a consistent state. Anexum documents retention, encryption, storage location, RPO, and RTO per contract. Recovery is considered tested only after login, core workflows, documents, scheduled jobs, APIs, and modules are verified.
Which components must be backed up?
The required set includes the MariaDB or MySQL database, Dolibarr document directory, relevant configuration files, scheduled tasks, and the complete version of every custom module. A database dump alone is insufficient for full recovery.
How is consistency achieved?
Backup order and maintenance mode depend on data volume and change rate. The database and documents must map to an auditable point in time. Active imports, scheduled jobs, and integrations are controlled during critical backup steps.
How are retention and storage defined?
Retention, offsite copies, encryption, and deletion are documented in the service package. This public page does not state universal periods because data volume, contract, protection needs, and regulatory requirements vary by customer.
How are RPO and RTO defined?
RPO describes the maximum tolerable data loss in time, while RTO describes the target recovery duration. Both are aligned before contract signature with backup frequency, infrastructure, data volume, test scope, and support window.
How is a restore test performed?
Recovery takes place in an isolated environment. The test then covers login, permissions, customers, products, quotes, orders, invoices, projects, inventory, documents, email, scheduled jobs, APIs, webhooks, and custom modules.
How are custom modules handled?
Each module records version, Git revision, dependencies, database migrations, permissions, triggers, hooks, APIs, and compatible Dolibarr versions. A restore without the matching module version can be functionally incomplete.
How is an update protected?
Compatibility, backup, maintenance window, test cases, and rollback are reviewed before updates. Core patches are avoided where possible. Extensions should run from the custom directory and use documented Dolibarr extension points.
Which evidence does the customer receive?
Evidence can include backup status, last restore-test date, tested version, verification steps, result, deviations, and open actions. Credentials and sensitive internal security details are not published.