What Portainer’s backup leaves to your recovery plan

FIELD NOTE · 30 SEPTEMBER 2026

Portainer has a backup feature, but recovering the Portainer installation and recovering the applications it manages are separate jobs. Start your plan by identifying which data belongs to each job.

The configuration layer

Portainer documents its backup as configuration stored in its own data directory. It explicitly excludes containers, volumes, application data in bind mounts and Docker or Kubernetes configuration outside its own database. Read Portainer’s backup scope.

The application layer

Inventory every named volume and bind mount in the application’s resolved Compose configuration. For each resource, record an owner, backup method, location of an independent copy, retention and the date of the last successful isolated restore. Treat missing information as an open question.

A database needs a method appropriate to that database and version. A copy of a volume while a database is writing does not, by itself, establish a usable backup. Use the database’s supported backup workflow and prove the result in a separate test environment. PostgreSQL backup documentation.

The recovery evidence layer

During a drill, record the exact backup restored, the clean destination, elapsed time, application checks, gaps and who reviewed the result. An entry saying “backup completed” describes a job outcome; it does not demonstrate that the application can be recovered.

Try a small inventory first

The free checker maps declared Compose storage and lets you record backup details locally. It cannot inspect files on your host, discover remote systems or verify recoverability. It gives you a list of questions to resolve before the drill.

Open the free recovery checker ↗

The paid Docker Recovery Kit adds the offline workspace, report exports and editable drill/runbook material. This page describes our own product; there are no affiliate links.