What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides 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
Moving a Docker or Compose application to a new server is two jobs, and only one of them is easy. Recreating the containers from your Compose file takes minutes. Getting a consistent copy of every place the application keeps state, restoring that state on the new host, and proving the app works before users arrive is the real work. Your priority is the data: preserve it first, then rebuild the containers around it.
This is a migration guide, not a recovery procedure. If the disk is already returning I/O errors or losing data, the steps below may fail partway through a copy. In that case, reduce writes immediately, copy the most valuable data first, and bring in storage recovery help before attempting anything else. The exact database, backup commands, and downtime tolerance depend on your application, so use its own backup documentation wherever it exists.
Why container recreation and data migration are separate jobs
Containers are disposable; application state usually is not. Docker stores named volumes outside the container lifecycle, so deleting a container normally leaves its volume in place. A volume on the old host, however, does not exist on the new one. Docker’s volume documentation treats volumes as something you can back up, restore, and migrate: you archive a volume’s contents on one host and unpack them into a volume on another. That is the mechanism used for file-level data in this guide.
Two shortcuts fail here. Copying /var/lib/docker wholesale is not a supported migration method, and docker cp on a running database directory does not give you a consistent database. Recreating the deployment from the Compose file rebuilds containers, but it does not bring the data along.
#1 Best Overall
- MADE FOR THE MAKERS: Create; Explore; Store; The T7 Portable SSD delivers fast speeds and durable features to back up any endeavor; Build your video editing empire, file your photographs or back up your blogs all in an instant
- SHARE IDEAS IN A FLASH: Don’t waste a second waiting and spend more time doing; The T7 is embedded with PCIe NVMe technology that brings fast read and write speeds up to 1,050/1,000 MB/s¹, making it almost twice as fast as the T5
- ALWAYS MAKE THE SAVE: Compact design with massive capacity; With capacities up to 4TB, save exactly what you need to your drive – from large working files to game data and everything in between
- ADAPTS TO EVERY NEED: Whether using a PC or mobile phone, count on the T7 for extensive compatibility²; It’s a true team player when it comes to heavy-duty application usage or file-saving
- HI RESOLUTION VIDEO RECORDING: Record Ultra High Resolution (4K 60fs) videos directly onto the T7 Portable SSD with your favorite camera or mobile devices; Supports iPhone 15 Pro Res 4K at 60fps video and more³
Step 1: Reduce writes and inventory the application
Work through these steps in order before copying anything.
- Reduce writes to the failing disk. Pause scheduled jobs and cron tasks, enable the application’s maintenance mode if it has one, and avoid heavy writes such as bulk imports, log rotation of large files, or package upgrades on that host. Do not run filesystem repair commands against a mounted disk as part of this migration.
- Record the deployment definition. Run
docker compose lsto find the project name, then save the Compose file, every.envfile, secret files, and a resolved copy of the configuration withdocker compose -f docker-compose.yml config > resolved-config.yaml. - List every mount for each container. Run
docker inspect -f '{{range .Mounts}}{{println .Type .Name .Source .Destination}}{{end}}' app-web-1for each service. Named volumes appear with aName; bind mounts appear with a hostSourcepath; anonymous volumes appear with long hash names. - Confirm the database engine, its exact image tag, and its major version, because you will need to match them on the destination.
- Copy the saved configuration and the application’s backup documentation to a location off the failing host before you start the data transfer.
Find every durable location, not just named volumes
A volume name tells you that data exists, not what it contains. Build a complete list of places where the application writes state that must survive a move.
| Where state lives | Typical examples | How to find it | What to preserve |
|---|---|---|---|
| Named volumes | Database data directory, uploaded files, search indexes | docker volume ls, docker compose config --volumes, and the mount list from docker inspect |
Archive each volume’s contents |
| Bind mounts | A host directory such as ./data mapped to a container path |
Compose volumes: entries that start with a host path |
Copy the host directory with ownership and permissions intact |
| Anonymous volumes | Volumes an image declared without a name | Long hash names in the docker inspect output |
Confirm whether the container writes meaningful state there |
| Database | PostgreSQL cluster or another engine’s data files | The image tag in the Compose file and the application’s documentation | A logical dump, or a copy taken under the conditions in Step 3 |
| Uploads and attachments | User files, documents, images | Application configuration and mount list | Copy with file ownership preserved |
| Configuration and secrets | .env files, secret key values, TLS certificates |
Compose env_file: and secrets: entries |
Copy off-host and keep values unchanged |
OpenProject’s migration guide shows how granular this inventory should be: it treats the database dump, attachments, configuration and secrets, and repository data as separate pieces. Your application may split its state differently, but the principle holds. Each category needs its own copy, its own restore step, and its own check.
Step 2: Prepare the destination
- Install Docker Engine and the Compose plugin on the destination using Docker’s official instructions for that operating system. Confirm with
docker compose version. - Match the application and database versions. Use the same image tags as the source unless you intentionally plan an upgrade, and treat a major-version database change as a separate project (covered below).
- Create destination volumes and bind-mount directories deliberately, using the names your Compose file expects. Check those names with
docker compose config --volumes. - Confirm the destination starts with the right amount of space. Measure the source data first, for example with
du -shon bind-mount directories and withdocker run --rm -v app_pgdata:/data alpine du -sh /datafor a named volume. - Keep the old and new hosts from accepting conflicting writes. Do not start the new stack against live traffic until the restore is complete and checked.
An empty destination volume is the most common silent failure. The application starts, shows a setup screen or a blank dashboard, and looks healthy, even though none of the data arrived.
Rank #2
- Get NVMe solid state performance with up to 1050MB/s read and 1000MB/s write speeds in a portable, high-capacity drive(1) (Based on internal testing; performance may be lower depending on host device & other factors. 1MB=1,000,000 bytes.)
- Up to 3-meter drop protection and IP65 water and dust resistance mean this tough drive can take a beating(3) (Previously rated for 2-meter drop protection and IP55 rating. Now qualified for the higher, stated specs.)
- Use the handy carabiner loop to secure it to your belt loop or backpack for extra peace of mind.
- Help keep private content private with the included password protection featuring 256‐bit AES hardware encryption.(3)
- Easily manage files and automatically free up space with the SanDisk Memory Zone app.(5). Non-Operating Temperature -20°C to 85°C
Step 3: Make a consistent final copy
The question “can I copy a Docker volume while the database is running?” matters more than any other in this migration. For a database, the answer depends on the engine and on how the copy is taken, so decide the method first and then run it.
Can I copy a Docker volume while a PostgreSQL database is running?
Not as a plain file copy. PostgreSQL’s documentation for file-system-level backup, in the PostgreSQL 17 manual, states: “The database server must be shut down in order to get a usable backup.” Files copied from a live cluster can be inconsistent in ways that look fine until you start the server or query the data. PostgreSQL also describes two alternatives: a consistent snapshot that includes the complete data directory and the required write-ahead log (WAL), taken simultaneously across filesystems if the data spans more than one, and a two-pass rsync approach in which the server is stopped for the final checksum pass. Check the manual page for your server’s major version before you rely on any of these methods.
Docker’s volume archive copies files, but it does not make a running database consistent. Treat the archive as a transfer mechanism, not as proof that a live database was captured correctly.
Preferred: take a dump with the database’s own tool
For PostgreSQL, a custom-format dump is usually the clearest path. It is logical, so it can move between hosts more easily than raw files, but it still requires the restore to match the application’s schema expectations. With the service running, take the dump:
Rank #3
- Capacity Display Variance: 250GB external ssd often appears as around 232GB on Windows. MacOS can show full 250 GB capacity. This is binary calculation difference and doesn’t affect SSD hard drive actual physical storage
- 1050 MB/s Speed: Instantly access to your files with blazing-fast 10Gbps external SSD read up to 1050MB/s and write up to 1000MB/s. LED Light indicates USB SSD instant activity
- Data Security: Solid state drives S.M.A.R.T. health diagnostics and adaptive TRIM optimizing data block management ensures consistent write speeds and extends the longevity of the portable SSD
- USB-C & USB-A Cable: Both cables featuring rapid USB 3.2 Gen2, this USB SSD effortlessly bridges devices, enabling seamless cross-platform file transfers and backup between computers, smartphones, tablets and iPhone
- Always Fast: No slowdowns for large file transfers. With SLC caching (25% of current available capacity allocated as high-speed cache), this external SSD delivers steady 10Gbps for transfers within the cache capacity
docker compose exec -T db pg_dump -U app -Fc appdb > appdb-$(date +%F).dumpHere db, app, and appdb are the example service, role, and database names; substitute your own. Confirm the file is readable before relying on it by listing its contents with pg_restore installed on the host: pg_restore --list appdb-2026-10-08.dump | head. For other engines, use that engine’s dump tool and documentation rather than assuming PostgreSQL behavior.
Alternative: stop the database and copy its volume
A stopped database is the simplest path to a consistent raw copy, at the cost of downtime for the duration of the copy. Stop the writers first so the database is not receiving traffic, then stop the database itself:
docker compose stop app worker
docker compose stop dbArchive the database volume with a helper container. The source is mounted read-only, and the archive is written to the current directory on the host:
Free tools Windows power users keep installed
One-click scans. No signup required.
docker run --rm -v app_pgdata:/source:ro -v "$PWD":/backup alpine tar -czf /backup/app_pgdata.tar.gz -C /source .
sha256sum app_pgdata.tar.gz > app_pgdata.tar.gz.sha256Confirm the archive is readable: tar -tzf app_pgdata.tar.gz | head. Then move it off the failing disk to the destination or to separate storage. An archive that lives only on the failing disk is not an independent backup.
Rank #4
- 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.
Non-database files and bind mounts
Uploads and other bind-mounted directories are not inside a Docker volume, so the volume archive above does not capture them. Copy them with a tool that preserves ownership, permissions, and timestamps. A common choice is rsync -a --numeric-ids /srv/app/uploads/ newhost:/srv/app/uploads/. The --numeric-ids flag keeps user and group IDs as numbers, which avoids mismatches if the destination’s user names differ.
Where to stage the backup
Stage the archive on a different physical device or on remote storage. A separate external drive works, including a portable SSD, and so does a second server. Size it from the measured data (du -sh), with room for the archive plus a second copy if you want one.
Comparing the backup methods
| Method | Consistency for a running database | Downtime | Best fit | Check before relying on it |
|---|---|---|---|---|
Engine dump (for example, pg_dump) |
Depends on the tool; check the engine’s documentation | Usually short; depends on the tool and data size | Moving between hosts, and sometimes between versions with care | List the dump’s contents and restore it into a scratch container |
| Stopped database, raw copy | Consistent after a clean shutdown; PostgreSQL requires shutdown for a usable raw copy | Lasts for the length of the copy and any transfer | Moderate-sized databases where a maintenance window is acceptable | Start the restored database and query representative records |
| Consistent filesystem snapshot or staged rsync | Possible only when the complete data and required WAL are captured together and simultaneously | Low, but requires the snapshot or final-pass stop to be planned correctly | Large clusters on filesystems that support consistent snapshots | Restore the copy to a scratch location and confirm the server starts cleanly |
| Docker volume archive | Moves file contents only; not proof of database consistency | Depends on whether the database is stopped during capture | Transferring any volume’s files between hosts | Confirm the archive lists and extracts, and that the restored data is usable |
If the move also changes the database version
A PostgreSQL major-version upgrade is not the same as moving a data directory. The new server binaries cannot read an older cluster’s files directly, and the pg_upgrade tool has version-specific constraints. Its link mode avoids copying data files, but it changes the old cluster: once the upgrade runs in link mode, the old cluster can no longer be started safely. Do not combine the host migration and a version upgrade in one step unless you have tested both.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsIf you need both, migrate the data at the existing version first, confirm the application works, and then plan the version upgrade as a separate change with its own backup.
Best Value
- NEARLY 2X FASTER THAN OUR PREVIOUS GENERATION(8) – move 1,000 high-res photos in under 60 seconds(6) with up to 2000MB/s transfer speeds(2).
- IP65 RATING AND UP TO 3M DROP PROTECTION(3) – protects against spills and drops.
- POCKET-SIZED – fits easily in pockets and small bags.
- SPACE TO OWN YOUR AI CONTENT – speed and capacity to download your high-res clips and photo edits.
- 256-BIT AES ENCRYPTION(4) – helps keep private files secure with password protection.
Step 4: Restore and validate before directing users to the new host
- Start only the database service on the destination and restore the dump into it. Use the same service and database names:
docker compose up -d db docker compose exec -T db pg_restore -U app -d appdb --clean --if-exists --no-owner < appdb.dumpThe
--no-ownerflag helps when role names differ on the destination. For a raw copy, restore the archive into the destination volume instead, with the database stopped:docker volume create app_pgdata docker run --rm -v app_pgdata:/target -v "$PWD":/backup alpine tar -xzf /backup/app_pgdata.tar.gz -C /target - Restore uploads and other bind-mounted directories to the exact paths the Compose file uses, and confirm ownership is still correct.
- Restore configuration and secrets. Keep secret values unchanged where the application uses them for sessions, tokens, or encryption. OpenProject’s migration guide, for example, warns that changing
SECRET_KEY_BASEinvalidates existing sessions and can disrupt some tokens. Other applications have their own equivalents, so check yours. - Start the full stack and inspect it before testing features:
docker compose up -d, thendocker compose psanddocker compose logs --tail=200. - Validate the application’s behavior, not only container status. Check the following against the source:
- Sign in with a real test account and confirm that existing sessions behave as expected.
- Compare counts of key records, such as users, projects, or orders, between the source and destination.
- Open a sample of uploaded files and attachments and confirm they load.
- Confirm background jobs and scheduled tasks run and the queue drains.
- Test any outbound feature the application depends on, such as email or webhooks, against a non-production target if possible.
Troubleshooting restore problems
- The application looks empty: the container is probably mounted to a new, empty volume or directory. Check the mount list again with
docker inspectand compare the volume names with the original. - Users are logged out or tokens fail: a secret or key value changed during the move. Restore the original value and restart the stack.
- Uploads return permission errors: the numeric user and group IDs on the destination do not match the files. Correct ownership to match the container’s user.
- A restored raw PostgreSQL copy will not start: the copy was probably taken from a running server or omitted files. Restore from a dump instead, and take the next copy with the server stopped.
Step 5: Cut over and keep the old host recoverable
Switch traffic only after the destination has passed the checks above. Change the DNS record, reverse proxy upstream, or load-balancer target according to how your deployment routes users. DNS propagation time, TTL settings, and the length of an acceptable rollback window depend on your environment, so measure them in your own setup and test your rollback plan before the switch.
After cutover, keep the old host stopped or read-only rather than deleting it. If both hosts accept writes, you have two diverging datasets and no safe way to merge them. If you must roll back, any writes accepted by the new host after cutover have to be exported and copied back deliberately, or they are lost.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows 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 reinstallQuick 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.
