Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers VPS plans with one-click Docker, NVMe storage and a 14-day free trial.
Portainer’s built-in backup is a tar.gz configuration archive of its /data volume. It can preserve Portainer’s database and stack files deployed through Portainer, but it does not copy running containers, services, Docker or Kubernetes settings outside Portainer’s database, or application data in named volumes and bind mounts. A recoverable plan therefore needs three separate layers: the Portainer archive, independently protected stack definitions, and application-data backups.
What Portainer’s built-in backup actually contains
An administrator downloads the archive from Settings > Back up Portainer. Portainer describes this feature as a configuration backup, not a backup of everything deployed to an environment. The download is a tar.gz copy of Portainer’s /data volume, and password protection can be enabled before downloading it.
| Item | In the Portainer archive | How to protect it |
|---|---|---|
| Portainer database | Yes | Download the archive after material changes and keep dated copies. |
| Portainer access-control records and environment metadata | Yes, as part of Portainer’s database | Protect the archive and its password. |
| Stack files deployed using Portainer | Yes | Also keep an independent copy of every definition. |
| Running containers, services and workloads | No | Recreate them from stack definitions after the Portainer instance is restored. |
| Named-volume contents | No | Back up each volume with a data-aware method. |
| Bind-mounted files and directories | No | Back up the host paths separately. |
| Docker or Kubernetes configuration outside Portainer’s database | No | Protect it using the platform’s own configuration and infrastructure-backup process. |
This boundary is the most important recovery fact: restoring the archive brings Portainer’s records back, but it does not make containers reappear with their old writable data. Portainer’s FAQ states that the archive includes the Portainer database and stack files deployed using Portainer; its documentation also explicitly excludes deployed containers, stacks, services and volumes as workload backups.
The three layers of a complete Portainer backup
1. Portainer configuration
The configuration archive is the quickest way to preserve users, access-control settings, registered environments, Portainer metadata and stack records. Enable password protection whenever the file could leave the host. Store the password in a secure secrets system rather than beside the archive, and keep multiple dated copies so one damaged or accidentally overwritten file does not become the only recovery point.
#1 Best Overall
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
2. Declarative stack definitions
A stack can be represented by a Compose file entered in Portainer’s Web Editor, an uploaded Compose file, or files pulled from Git. The archive may preserve stack files deployed through Portainer, but an independent repository is a stronger source of truth: it can be reviewed, versioned and recovered even if the Portainer archive is lost.
For Git-deployed stacks, protect the repository, the exact branch or tag used for deployment, the deploy key or other credentials, and the environment-variable material required by the stack. Keep secrets out of ordinary Compose files where possible; record where each required secret is stored and how it will be re-created during recovery.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute3. Application data
Databases, uploads, certificates and other state live in named Docker volumes or host directories mounted into containers. Their contents are outside Portainer’s archive. Back up every named volume and every bind-mounted path that contains state, using a method that is consistent with the application writing the data.
Inventory everything before choosing a schedule
A backup is only complete when you can identify every dependency needed to start the service again. Create and maintain an inventory with these entries:
- Every Docker or Kubernetes environment registered in Portainer, including the endpoint used to reconnect it.
- Every stack, its deployment method (Web Editor, uploaded file or Git), and the exact Compose file or repository revision.
- Every named volume, the services that use it and the host or storage system on which it resides.
- Every bind mount, including the full host path and the files that must be restored there.
- Secrets, environment variables, certificates and external networks referenced by each stack.
- The location and permissions of the
portainer_datavolume that stores Portainer’s own data.
External networks and platform-level settings are not recreated by importing a Portainer archive. Include their creation procedure or infrastructure configuration in the runbook, even when the application data itself is backed up elsewhere.
Rank #2
- Easily store and access 5TB of content on the go with the Seagate portable drive, a USB external hard Drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Step by step: create a protected Portainer configuration backup
- Sign in with an administrator account. Use the Portainer instance that owns the environments and stacks you need to recover.
- Open Settings. Select Back up Portainer in the settings area.
- Turn on password protection. Set a strong, unique password if the archive will be copied to removable, shared or off-site storage. Save the password in your approved secrets manager.
- Download the archive. Portainer produces a
tar.gzfile containing its/datavolume contents. - Give the file a dated, unambiguous name. Include the Portainer instance or environment name and the backup date, while keeping the password separate from the filename.
- Copy it to more than one protection domain. Keep a local copy for fast access, a separate storage copy such as a USB external hard drive, and an off-site or S3-compatible copy when your recovery plan requires geographic separation.
Repeat this operation after material changes to users, access control, registered environments or stacks. The archive is small compared with application data, so configuration backups can usually be retained more frequently than full volume backups.
Back up stacks in a way that survives a Portainer failure
Web Editor and uploaded Compose files
Export or copy each Compose definition into a controlled repository. Record the stack name, target environment, required variables, external networks, volume declarations and any file paths referenced by bind mounts. Keep a readable version history instead of relying on the copy embedded in one Portainer archive.
Before committing, remove passwords, API keys and private certificates from ordinary files. Store a reference to the secret location and document the procedure for supplying it during redeployment. A Compose file that cannot be rendered without undocumented variables is not an independently recoverable stack.
Git-deployed stacks
Back up the Git repository itself and retain the revision that was deployed. A recovery operator needs the repository URL, branch or tag, deploy credentials, submodules if used, and all non-secret variables. If the repository changes after deployment, note the deployed commit so a restore does not silently pull an incompatible version.
Why two copies are useful
The Portainer archive is convenient because it preserves stack records inside Portainer’s database. The repository is independent and reviewable. Keeping both protects against a damaged archive, an accidentally deleted repository revision, or a deployment that was edited in Portainer but never committed elsewhere.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Rank #3
- Easily store and access 1TB to content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop. Reformatting may be required for Mac
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Back up named volumes and bind mounts without corrupting data
Named volumes
Docker defines named volumes as persistent data stores. A volume can be shared by services through Compose declarations, so inventory the volume once but list every service that depends on it. Preserve the volume’s contents, ownership, permissions and the destination path expected by the application.
Do not assume that copying a volume’s files while a database is writing produces a usable backup. Follow the database vendor’s consistency procedure: stop the database, place it in a supported backup mode, or take an application-consistent dump before archiving the underlying files. The correct choice depends on the database engine and its durability requirements.
Bind-mounted paths
Back up every host directory or file mounted into a container when it contains databases, uploads, certificates, configuration or other state. Record the absolute path, filesystem ownership and permissions. A Portainer restore will not recreate these paths or repopulate them.
Verify the resulting archives
- Check that each archive can be read and listed from the destination storage.
- Confirm that expected database dumps, upload directories, certificates and configuration files are present.
- Keep checksums or equivalent integrity records when your storage process supports them.
- Perform an actual restore rehearsal rather than treating a successful copy operation as proof of recoverability.
Keep Portainer’s own data attached to the right host
The portainer_data volume contains the Portainer data that the configuration archive represents. Document where that volume lives and how it is mounted. In Docker Swarm, constrain the Portainer service to a node that has the persistent data, or use storage available to the service wherever it is scheduled. If a rescheduled service starts with an empty data volume, it can look like a fresh Portainer installation even though the old service definition still exists.
This placement issue is separate from application-volume protection. You need both: durable storage for Portainer’s own data and independent backups for the volumes used by deployed applications.
Rank #4
- 【Versatile Storage Expansion – For Gaming, Work & Everyday Use】 Running out of space on your PS5 or Xbox Series X/S? This external hard drive lets you store and play PS4 / Xbox One games directly, instantly freeing up your console’s internal storage for next‑gen titles. At the same time, it handles work file backups, media libraries, and cross‑device data transfers with ease. One drive, all your needs. *（Note: PS5 / Xbox Series X|S games cannot be run or stored directly from the external hard drive. However, by offloading your PS4 / Xbox One games, you can free up valuable space for newer titles.）*
- 【Patented Silicone Sleeve – Data Protection You Can Count On】 Worried about drops? We’ve got you covered. The patented built‑in silicone sleeve acts like a shock‑absorbing armor, cushioning your drive against bumps and falls. Whether it’s important work documents, precious family photos, or hard‑earned game saves, your data deserves this level of protection.
- 【Plug & Play, Compatible with Computers & Consoles】 No complicated setup—just plug in and go. Works seamlessly with Windows, Mac, and Linux computers, as well as PS4, PS5, Xbox One, and Xbox Series X/S. Process files at the office, back up data at home, or enjoy gaming in your downtime—one drive handles all your devices, simply and hassle‑free.
- 【USB 3.0 Ultra‑Fast Transfer – No More Waiting】 Tired of watching progress bars crawl? With USB 3.0 speeds up to 5Gbps, large files transfer in seconds. Whether you’re moving work documents, transferring hundreds of gigs of games, or backing up a year’s worth of photos, you get more done in less time.
- 【Sleek, Lightweight, and Ready to Go】 Weighing just 0.16 kg—lighter than a can of soda—this compact drive features a stylish mirror‑and‑frosted finish. Toss it in your bag and go, whether you’re heading to the office, visiting a friend for a gaming session, or giving a presentation on the road.
Restore Portainer on a new server
Portainer documents a fresh-instance requirement for importing a configuration archive. Start with a new Portainer instance whose data volume is empty; do not try to merge the archive into an already populated installation.
- Prepare the replacement host. Install the required container or orchestration runtime, create the persistent location intended for Portainer’s data, and ensure the host can reach the environments that will be managed.
- Deploy a fresh Portainer instance. Use an empty data volume. Complete only the initialization needed to reach the restore function.
- Restore during initialization. Select the Portainer backup archive and enter its password when prompted. Import the archive into the fresh instance rather than copying individual database files by hand.
- Reconnect environments. Verify each Docker or Kubernetes endpoint, credentials, certificates and network route. Environment records can be restored, but the replacement host still needs working connectivity and valid credentials.
- Recreate platform prerequisites. Re-establish external networks, node labels, storage classes or other Docker and Kubernetes settings that were outside Portainer’s database.
- Restore application data separately. Recreate named volumes and bind-mounted directories, then restore database-consistent dumps or file archives into the locations expected by the stacks.
- Redeploy stacks. Use the restored stack records when appropriate, or deploy the independently versioned Compose files and the recorded Git revision. Supply the required variables and secrets.
- Validate service behavior. Check container health, database integrity, uploaded files, certificates, scheduled jobs, external network access and Portainer permissions before declaring the recovery complete.
Importing the archive does not start the old containers or restore their writable layers. Those workloads must be redeployed, and their state must come from the separate volume and bind-mount recovery process.
Free tools Windows power users keep installed
One-click scans. No signup required.
Use a restore rehearsal to measure whether the plan works
Periodically test the complete sequence on an isolated host. Deploy a fresh Portainer instance with an empty data volume, import a dated archive, reconnect a test environment, redeploy representative stacks and restore their application data. Record where the procedure depends on a missing credential, undocumented variable, unavailable Git revision or host path.
A useful review evaluates every backup design on four axes:
| Recovery question | What a satisfactory plan demonstrates |
|---|---|
| Are stack definitions declarative and versioned? | A Compose file or exact Git revision can be obtained without relying solely on the live Portainer UI. |
| Is data application-consistent? | Database and volume backups follow the application’s supported quiescing or dump procedure. |
| Are copies isolated or off-site? | A lost host, damaged local disk or single operator error cannot destroy every copy. |
| Has a full restore been rehearsed? | The team has completed a fresh-instance import, environment reconnection, data restore and stack redeployment on an isolated host. |
Common mistakes and how to correct them
“The archive downloaded, so all applications are backed up.”
Why it fails: The archive is for Portainer configuration and selected stack records, not workload data. Correction: add named-volume and bind-mount backups, and keep the Compose or Git source independently.
Best Value
- High capacity in a small enclosure – The small, lightweight design offers up to 6TB* capacity, making WD Elements portable hard drives the ideal companion for consumers on the go.
- Plug-and-play expandability
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
“The stack is in Portainer, but nobody knows which variables it needs.”
Why it fails: A Compose file without its non-secret variables, secrets and external-network requirements cannot be redeployed reliably. Correction: document every required input and where sensitive values are stored.
Recommended Free Tools
“A live database directory was copied like ordinary files.”
Why it fails: In-flight writes can leave an internally inconsistent database. Correction: use the database vendor’s dump or quiescing procedure, then verify the restored data.
“Portainer came back empty after a Swarm reschedule.”
Why it fails: The service started on a node without the persistent portainer_data volume. Correction: constrain placement to the node with the data or provide service-wide persistent storage, and retain the configuration archive for recovery.
“The restore was attempted over the existing installation.”
Why it fails: Portainer’s documented import flow expects a fresh instance. Correction: deploy a new instance with an empty data volume and import the archive during initialization.
“Only one copy exists on the same server.”
Why it fails: Disk failure, ransomware or an operator mistake can remove both the live data and its backup. Correction: keep dated copies in separate storage, with an off-site or S3-compatible copy when required by the recovery plan.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Security and retention practices
- Use password protection for archives that leave the Portainer host.
- Store the archive password separately in a managed secrets system and limit access to recovery personnel.
- Protect Git deploy keys, repository credentials, environment-variable files and certificates as carefully as the archive.
- Retain several dated configuration archives so you can select a known-good point before an accidental change.
- Review access permissions on USB, local and object-storage destinations.
- After every significant restore rehearsal, update the runbook with the exact host paths, credentials, variables and sequence that worked.
A practical backup checklist
- Download a password-protected Portainer archive from Settings > Back up Portainer.
- Keep several dated copies and record the password in a secure secrets system.
- Export or commit every Web Editor and uploaded Compose file.
- Back up Git repositories, deployed revisions, deploy credentials and non-secret variables for Git stacks.
- Inventory and back up every named volume and stateful bind-mounted path.
- Use database-consistent dumps or quiescing procedures where required.
- Document
portainer_dataplacement, Swarm constraints and storage dependencies. - Copy archives to separate local and off-site or S3-compatible storage when appropriate.
- Rehearse a fresh-instance restore, environment reconnection, data restore and stack redeployment on an isolated host.
The result is a layered recovery plan rather than a single download: Portainer’s configuration can be imported, stack definitions can be reproduced independently, and application state can be restored from verified data backups.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
