How to Recover a Site When Your Backup Provider Disappears

When a backup provider shuts down or locks you out, your site is usually still running on its live host, and the only thing you have lost is the ability to restore it. That is the good news, and it changes the whole shape of the job. Backup provider shutdown recovery is mostly about getting the backup data back out, or, if that fails, rebuilding a restore path before the next failure happens.

Start by separating two questions. Is the live site still up, and do you still control the domain and the hosting account? If yes, you are not in an emergency. You are in a data extraction and re-architecture project, and you should treat it that way rather than wiping anything in a panic.

Find out what you can still reach

Most backup services expose at least one of three things: an S3-compatible object store, a web dashboard, or a local agent that keeps a cache. Even when the company has gone dark, the object store backing it may still answer for a while, because the storage was often rented from a third party and the shutdown notice did not reach the storage layer yet.

If you have credentials, test the endpoint directly rather than through the vendor's dashboard. An S3-compatible API is the most common shape, and the credentials usually look like an access key and a secret.

aws s3 ls s3://my-backups/ --endpoint-url https://storage.example.net --recursive

2024-01-05 09:14:22   104857600 daily/site-2024-01-05.tar.gz
2024-01-04 09:12:01   104726528 daily/site-2024-01-04.tar.gz
2024-01-03 09:11:47   104699904 daily/site-2024-01-03.tar.gz

Replace the endpoint with whatever the vendor documented. If the listing works, copy everything out immediately with aws s3 sync to storage you control. Do not try to be selective. Disk is cheap compared with the cost of discovering later that the one file you skipped was the one you needed.

If the endpoint refuses connections, try the HTTP layer. Sometimes a CDN or reverse proxy still serves the objects even when the API is gone. A plain curl against a known object URL will tell you in one request.

curl -I https://cdn.example.net/backups/site-2024-01-05.tar.gz

HTTP/1.1 200 OK
Content-Length: 104857600
Content-Type: application/gzip

Watch the response headers. A 200 means you can fetch it. A 403 usually means the object exists but your key is no longer valid, which is a different problem from the object being gone. A 404 from a CDN often means the origin has been decommissioned. If you get a 200, pull the objects down with curl -O or wget -r and do not stop until the transfer is complete.

What to do when the data is truly gone

If the API, the CDN and the dashboard are all dead, accept that the backup chain is broken and shift to rebuilding. The live site is now your only copy, so the first move is to make a new one. Dump the database, archive the document root, and copy both off the server before you touch anything else.

mysqldump --single-transaction --routines --triggers mydb | gzip > mydb.sql.gz
tar --exclude=./cache --exclude=./tmp -czf webroot.tar.gz ./public_html

The --single-transaction flag matters on InnoDB tables because it gives you a consistent snapshot without locking writes for the duration. If you are on PostgreSQL, pg_dump -Fc produces a custom-format archive that restores more flexibly than plain SQL. Either way, verify the archive before you trust it. A truncated dump that looks fine until restore day is the classic failure mode.

Then reconstruct the configuration that the backup service was silently covering for you. This is where most people discover that their recovery plan was really just a vendor's recovery plan. Write down the things you need to be able to rebuild from scratch: the web server config, the PHP or runtime version, the cron entries, the TLS certificate and its renewal method, the DNS records, and the list of environment variables the application reads.

DNS is the one people forget. If the backup provider also ran your DNS, your zone file is part of the lost data. Check the authoritative nameservers with dig and write down every record you can still see, because once the nameservers stop answering you cannot query them again.

dig +short NS example.com
dig +short MX example.com
dig +short TXT example.com

Copy those answers into your own notes, then move the zone to a registrar or DNS host you control. Lower the TTL on the records you are about to change well before you change them, so the cutover is quick.

Rebuild the backup path so this cannot repeat

The real lesson from a backup provider shutdown recovery is that a backup you cannot restore without the vendor is not a backup. It is a subscription. The fix is to make the restore path depend only on things you own: your own credentials, your own storage, and a documented procedure that does not require anyone else's dashboard.

Point your backup tool at an S3-compatible endpoint you control and keep the credentials in your own secret store. The tool does not matter much. What matters is that the destination is a plain object store you can read with aws s3 or curl and nothing else. Vendor-specific formats and proprietary restore tools are the trap.

Then test the restore. Not the backup, the restore. Spin up a throwaway container, pull the newest archive, and bring the site up from it. Do this on a schedule you will actually keep. A restore you have never run is a guess, and guesses fail at the worst possible moment.

Keep at least one copy somewhere that a single account compromise cannot reach. Object storage with versioning and an object lock, or a second provider with different credentials, both work. The point is that losing access to one account should not mean losing every copy at once.

Finally, keep the recovery instructions somewhere outside the system they describe. A short file in a password manager, listing the endpoints, the bucket names, the commands and the order to run them, will save you more time than any tool. When the next provider disappears, you will not be reconstructing this from memory.

What to do next: today, log in to whatever holds your backups and confirm you can list the objects with your own tooling, not the vendor's interface. If you can, sync a full copy to storage you control. If you cannot, treat the live site as your only copy and dump it now. Then write the restore steps down and run them once against a scratch environment before you need them for real.