Zeabur: restore elsewhere, rehearse, then move traffic

Operator playbook · checked 22 October 2026 · migration owner: __________ · expiry: __________

Two-minute applicability and containment check

Record each service's actual expiry. From 1 December 2026, dedicated servers stop renewing and shut down at individual expiry; shared-cluster services pause, with manual restart for backup. 31 December is the final shutdown, not a promise that your service lasts until then. Export/deletion/support deadlines remained unfinalized in the founder's notice.

If compromise is suspected, isolate the service and preserve incident evidence before treating its files as migration inputs. A migration does not remove malicious database objects or revoke exposed credentials. Use fresh destination secrets and separately revoke the old ones at their issuers.

Inventory and choose the destination

Record source repository/commit or image, start/build command, database engine/version/extensions, persistent volumes/uploads, background workers, schedules, queues, network routes, environment-variable names, domains/DNS and external integrations. Keep private configuration exports separately. Include registrar/domain transfer in the plan; moving an application does not move its domain registration. Zeabur migration guide, domain arrangements

Choose your destination before exporting: confirm matching database extensions, storage capacity, backup/restore tools, private connectivity, TLS, worker support and cost. Use its official provisioning/restore guide and create an isolated rehearsal environment. Do not open production traffic or enable outbound jobs there yet. The steps below describe a PostgreSQL logical migration; MySQL, MongoDB, Redis and filesystem volumes require their own native format and restore procedure.

Export beyond Zeabur's retention window

Zeabur's backup interface supports online database exports; PostgreSQL exports are SQL files. For other volume-backed services, its documented offline flow is Settings → Suspend Service → Backup → download → restart. These volume backups exclude files outside mounted volumes, including application source. Download copies to private storage outside Zeabur; the backup documentation specifies seven-day retention. Confirm the live interface still offers these features. Zeabur backup documentation

Record backup start/end times, source identity, file size and checksum, tool version, warnings and exit status. Export all databases and file stores the application needs. PostgreSQL pg_dump covers one database, not cluster roles/tablespaces; identify those separately. Use a client version compatible with the source and destination: pg_dump refuses a source newer than its own major version. PostgreSQL export reference

PostgreSQL rehearsal: no passwords in commands

On a trusted migration machine, configure two connection-service entries, SOURCE_DB and DEST_EMPTY, with verified host, port, database, user and provider-required TLS settings. DEST_EMPTY must point to a newly created empty rehearsal database, using a restore role. Use a password prompt or a private password file; on Unix it must deny group/world access. These names are placeholders, not ready-made connections.

In a new private working directory, using a new filename for each attempt, run one command at a time and stop on error:

pg_dump --dbname='service=SOURCE_DB' --format=custom --file=database.dump

Stop on export failure. After a successful export, inspect the new archive:

pg_restore --list database.dump > database-contents.txt

Stop on any error and review warnings. The listing establishes readable archive structure only. A dump can contain executable database logic; if source integrity is uncertain, have it reviewed before restoration. Never send the archive to an online checker. Export behavior and trust warning

After destination extensions and the permissions plan are prepared, restore the reviewed custom-format archive:

pg_restore --dbname='service=DEST_EMPTY' --single-transaction --no-owner --no-acl database.dump

This rolls back on a restore error. It intentionally omits original ownership/grants: recreate appropriate application roles and privileges before testing. Do not run the application as the restore administrator. For large databases, single-transaction limits may require a DBA-designed alternative. No --clean or database-dropping command is needed. Restore options

Downloaded `.sql` branch: a Zeabur SQL export uses psql, not pg_restore. Review it first, then use a fresh empty target:

psql -X --dbname='service=DEST_EMPTY' --set=ON_ERROR_STOP=on --file=zeabur-backup.sql

A failure can leave partial objects; retain the failure and use another empty rehearsal database for the next attempt. psql reference

Validate, cut over and retain recovery options

Compare representative record counts, newest records, attachments and business totals against the same backup point. Deploy the application against restored data; test login, reads, a reversible test write and background processing without sending real notifications/payments. Record duration to establish a realistic outage window.

Schedule cutover: stop source writes and workers, take the final consistent export/files copy, restore to an empty production destination, repeat checks, then update application connections and DNS. Verify TLS, callbacks and representative requests through the public domain. Start destination workers once; keep source workers stopped to prevent duplicate jobs. Preserve the old system privately.

If verification fails before destination writes, return traffic to the retained source only if it is safe and still available. Once new writes occur, freeze writes and reconcile data before reversing traffic; blindly switching DNS loses/diverges data. Escalate missing exports, restore errors or expiry conflicts immediately.

Output limit: retain archives and full logs privately; share counts, checksums, timestamps and redacted errors only. A checksum does not prove completeness.

• [ ] Deadline, destination and every stateful dependency recorded.
• [ ] Off-platform backups downloaded and restore rehearsed.
• [ ] Roles, data comparisons and application checks pass.
• [ ] Final write freeze/export/cutover verified; one worker set active.
• [ ] New backups tested; rollback/data reconciliation owner assigned.