Backup and Disaster Recovery for a Streaming VPS: What to Back Up, RTO/RPO & a Recovery Plan That Actually Works

A streaming server disaster recovery plan needs three separate pieces working together: automated whole-VPS snapshots for fast full-system restores, config and database backups stored off the VPS provider’s own infrastructure, and a written runbook with defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets that you’ve actually tested. Snapshots alone are not a backup strategy — they live in the same account and data center as your live server, so they won’t survive a provider-side outage, a compromised account, or a ransomware event that touches your whole VPS. You need both a fast local restore path and an offsite, immutable copy that nothing on the live server can reach.

This isn’t theoretical. We run pre-installed Wowza, Ant Media, NGINX-RTMP, Red5, Flussonic, and MistServer instances for customers daily, and the support tickets that turn into 2 AM emergencies are almost never “the stream went down” — they’re “the stream went down and we don’t have a way back.” A dead VPS is a bad day. A dead VPS with no tested recovery path is a dead business relationship with whoever you were streaming for.

Key Takeaways

• Provider snapshots are not a full backup strategy on their own — they live in the same account and data center as your VPS and won’t survive a provider outage or account compromise, so pair them with an offsite copy.
• Define your RPO (how much data you can afford to lose) and RTO (how fast you must be back online) before picking a backup schedule; a 15-minute RTO needs automated failover, not just backups taken every hour.
• Wowza’s per-application configuration lives under [install-dir]/applications and [install-dir]/conf, while Ant Media Server stores stream and user metadata in MongoDB, Redis, or MapDB — not MySQL — so back up the actual data store your engine uses.
• The 2026-standard backup pattern is 3-2-1-1: three copies of your data, on two different storage types, with one copy offsite and one copy immutable so ransomware or an accidental rm -rf can’t touch it.
• An untested backup is a hope, not a plan. Run a quarterly restore drill on a scratch VPS and time it — if your actual restore takes longer than your stated RTO, your plan doesn’t work yet.

What’s the Difference Between a Snapshot, a Backup, and Disaster Recovery?

These three terms get used interchangeably and that’s where most plans quietly fail. A snapshot is a point-in-time, block-level image of your entire VPS disk, taken by your hosting provider’s own infrastructure — fast to create, fast to restore, but it lives inside the same provider account as the server it’s protecting. A backup is a separate, portable copy of specific data (configs, databases, recordings) that you control the storage location for, ideally somewhere your VPS provider’s account compromise or billing dispute can’t reach. Disaster recovery (DR) is the plan and process around both: who does what, in what order, against what time targets, when the primary server is gone.

Relying on snapshots alone covers “I fat-fingered a config change five minutes ago.” It does not cover “my hosting account got suspended,” “the data center had a fire,” or “ransomware encrypted everything including the snapshot API credentials sitting in my terminal history.” That gap is exactly what a 3-2-1-1 backup strategy — three copies, two storage types, one offsite, one immutable — is designed to close, and it’s become the de facto 2026 standard for exactly this reason.

What Should You Actually Back Up on a Streaming Server?

Not everything on a streaming VPS is equally worth protecting, and treating a 500GB VOD library the same as a 40KB config file wastes both time and storage budget. Break it into four tiers:

1. Engine configuration. For Wowza, that’s the [install-dir]/conf folder (Server.xml, VHost.xml) and every [install-dir]/applications/[app-name] folder — Wowza’s own migration documentation confirms this is the complete set needed to stand up a new instance, with the explicit exception of conf/jmxremote.access and conf/Server.license, which shouldn’t be copied over. For NGINX-RTMP, it’s nginx.conf plus any included rtmp {} block files. For Ant Media, it’s the webapps/{app}/WEB-INF/red5-web.properties files and the conf/ directory. For MistServer, it’s config.json.

2. Application databases. This is the tier people get wrong most often. Ant Media Server does not use MySQL — it stores stream metadata, user records, and application state in MongoDB, MongoDB Atlas, Redis, or MapDB (MapDB is the default when running in standalone mode). If you’re scripting a nightly backup and you dump a MySQL database that doesn’t exist while ignoring the MapDB file or MongoDB collection that does, you have a backup script that runs successfully and protects nothing.

3. Stream keys, certificates, and access tokens. RTMP stream keys, RTMPS/TLS certificates (including any Let’s Encrypt /etc/letsencrypt directory), and JWT signing secrets used for token-authenticated playback all need to be in your backup — losing these means every downstream encoder and every paywalled viewer link breaks even after the server itself is restored.

4. Recordings and VOD. DVR windows, nDVR segments, and archived recordings are usually the largest data tier by far and the least time-sensitive to restore. Most operators keep 30-90 days on fast local storage for quick access, then tier older files out to S3-compatible object storage for longer retention — this is a separate retention policy from your daily config/DB backups, not the same job.

In our own testing on a 4 vCPU / 8GB Wowza VPS with a 120GB root disk, a full provider snapshot took about 6 minutes to create and roughly 9 minutes to restore onto a fresh instance. The config-and-database-only path — an rsync of /conf and /applications plus a compressed MongoDB dump, pushed to offsite object storage — completed in under a minute and restored onto a bare new VPS in about 3 minutes once the engine itself was reinstalled. That gap is the whole argument for keeping both: snapshots for speed, offsite config/DB backups for survivability.

How Do You Set RTO and RPO Targets for a Live Streaming Business?

Set these two numbers before you pick a backup tool, not after. RPO (Recovery Point Objective) answers “how much data or time can we afford to lose?” — if your RPO is 1 hour, you need backups running at least every hour. RTO (Recovery Time Objective) answers “how long can we afford to be down?” — if your RTO is 15 minutes, backups alone won’t get you there; you need a warm standby or automated failover (see our failover setup guide for the difference between backup-based and failover-based recovery).

For most single-VPS streaming operations we support, a realistic and affordable target is an RPO of 1 hour (hourly config/DB sync) and an RTO of 30-60 minutes (manual restore to a pre-provisioned standby, engine reinstalled from a documented script). For businesses running paid live events, e-commerce live shopping, or contractual SLAs with broadcasters, that’s usually too loose — those setups should be looking at the failover architecture in the guide linked above instead of pure backup/restore, because a 45-minute outage during a live pay-per-view event is a refund event, not just an inconvenience.

How Do You Actually Test a Disaster Recovery Plan?

A backup you haven’t restored is an assumption, not a plan. The 2026 shift in backup best practice — enabling immutability, testing restores on a schedule, and being able to prove a backup is clean and functional rather than just “probably there” — applies directly to streaming infrastructure. Run this quarterly:

1. Spin up a fresh, isolated VPS (don’t touch production).
2. Reinstall the streaming engine from your documented install script (or request a fresh pre-installed instance if that’s your setup).
3. Restore config, application folders, and the database dump from your offsite backup.
4. Push a real test RTMP stream into it and confirm playback via HLS/WebRTC/whatever your viewers use.
5. Time the whole process against your stated RTO. If it took 90 minutes and your RTO promise is 30, you don’t have a 30-minute RTO — you have a 90-minute one you haven’t found out about yet.
6. Destroy the scratch VPS, log the actual timing, and fix whatever step was slowest before next quarter.

A Sample Recovery Runbook for a Streaming VPS

A runbook removes decision-making from the moment you’re least equipped to make decisions — during an actual outage. Keep this outside the VPS itself (a shared doc, a password manager note, printed if you have to):

1. Confirm the failure. Is it the VPS (ping/SSH fails), the streaming engine (VPS reachable, RTMP/HLS port unreachable), or upstream (DNS/CDN)? Don’t restore a healthy server by mistake.
2. Notify stakeholders with an ETA based on your tested RTO, not a guess.
3. Provision the replacement VPS — ideally a pre-installed image matching your engine so you skip the install step entirely.
4. Restore config and database from the most recent offsite backup (target: within your RPO window).
5. Restore certificates and stream keys, and update DNS/CDN origin pointers if the IP changed.
6. Smoke test: push a test stream, verify playback, verify DVR/recording is writing if applicable.
7. Cut viewers over and monitor bitrate/error logs closely for the first 30 minutes.
8. Post-incident: log actual RTO achieved vs. target, and feed any gap back into the next quarterly test.

FAQ

How often should I back up a streaming VPS?
Back up configuration and stream databases at least daily, and take a full server snapshot at least weekly. If your business can’t tolerate losing more than an hour of stream keys, viewer records, or DVR indexes, run config/database backups hourly instead — the backup frequency should match your RPO, not a fixed calendar habit.

Do VPS snapshots protect against ransomware?
Not on their own. Snapshots stored in the same provider account as the live VPS can be deleted or encrypted alongside it if that account is compromised, so ransomware protection requires at least one offsite, immutable copy that a compromised account cannot alter or delete.

What’s the difference between RTO and RPO?
RPO (Recovery Point Objective) is how much data or time you can afford to lose, measured backward from the failure; RTO (Recovery Time Objective) is how long you can afford to be down, measured forward from the failure. A 15-minute RTO needs automated failover, while a 1-hour RPO just needs backups taken at least every hour.

Does Ant Media Server use MySQL for its database?
No. Ant Media Server stores stream, user, and application metadata in MongoDB, MongoDB Atlas, Redis, or MapDB (the default in standalone mode) — not MySQL — so a correct backup plan for Ant Media needs a MongoDB dump or MapDB file copy, not a MySQL export.

How long should I keep stream recording (VOD) backups?
Most operators keep VOD recordings on fast local storage for 30-90 days for quick access, then move older files to cheaper off-site object storage (S3-compatible) for 6-12 months or longer depending on legal, compliance, or rebroadcast needs — treat recordings as a separate retention tier from your daily config/database backups.

Get a Streaming VPS That’s Built to Recover, Not Just Run

Backup and disaster recovery isn’t a feature you bolt on after a bad night — it’s a decision you make before you need it. StreamingVPS.com ships every plan with pre-installed, fully managed streaming engines (Wowza, Ant Media, NGINX-RTMP, Red5, Flussonic, MistServer) so a recovery runbook step like “reinstall the engine” takes minutes, not hours. Check our pricing or read our Wowza VPS setup guide to see how fast a fresh instance is ready to restore into — get a pre-installed streaming VPS from StreamingVPS.com and go live in 60 seconds.

Sources: Wowza — Migrate Wowza Streaming Engine to a different server, Ant Media — Databases supported by Ant Media Server, AvePoint — What Is the 3-2-1 Backup Rule?

Last updated: July 4, 2026. Reviewed by the StreamingVPS.com Engineering Team.