Self-hosting an IoT stack means accepting that backups, unlike on a managed platform, are entirely your responsibility, and a VPS provider’s own snapshot feature alone usually isn’t enough. A combination of automated, encrypted offsite backups using a tool like restic, alongside provider snapshots for fast full-system recovery, covers the realistic range of failures, from accidental misconfiguration to total VPS loss, that self-hosted infrastructure can actually experience.
The problem self-hosting quietly creates
Every guide on this site that recommends self-hosting over a managed platform is implicitly asking the reader to take on a responsibility managed platforms handle invisibly: backups. A managed IoT platform’s data loss is the vendor’s problem to prevent and recover from. A self-hosted VPS’s data loss, the months of telemetry history in InfluxDB, the carefully built Node-RED flows, the ThingsBoard dashboard configuration, is entirely the operator’s problem, and it’s a genuinely easy thing to defer indefinitely until the day it’s suddenly, expensively too late.
VPS snapshots: necessary, not sufficient
Most providers covered in Best Low-Cost VPS Providers for IoT offer a built-in snapshot feature, a full point-in-time image of the entire VPS, genuinely useful for fast recovery from a catastrophic failure or a botched system update. The limitation worth understanding: snapshots typically live on the same provider’s infrastructure, meaning a genuinely severe provider-side incident, however rare, could affect both the live VPS and its snapshots simultaneously. Snapshots are a strong first layer, not a complete backup strategy on their own.
A practical layered approach
| Layer | What it covers | Recovery speed |
|---|---|---|
| Provider snapshots | Fast full-system recovery from major failures | Minutes to an hour |
| Automated offsite backups (restic or similar) | Specific data, configs, databases, recoverable independently of the VPS provider | Slower, but provider-independent |
| Configuration as documentation | The ability to rebuild from scratch if both of the above somehow fail | Slowest, but the ultimate fallback |
Setting up restic for the genuinely important data
Restic is a well-regarded, encrypted, deduplicating backup tool that supports a wide range of storage backends, including S3-compatible object storage from many providers, separate from whichever VPS provider hosts the live infrastructure:
# Initialise a new backup repository (once)
restic -r s3:https://your-bucket-endpoint init
# Run a backup
restic -r s3:https://your-bucket-endpoint backup
/etc/mosquitto /var/lib/influxdb2 /opt/thingsboard/conf
--tag iot-vpsThe specific paths worth backing up vary by which services from this site’s other guides are running, but the general principle holds: configuration directories, database data directories, and anything that took real time to build (Node-RED flow exports, Grafana dashboard JSON exports) are the priority, not the entire operating system, which provider snapshots already cover.
Automating it properly
# crontab entry, daily at 2am
0 2 * * * restic -r s3:https://your-bucket-endpoint backup /etc/mosquitto /var/lib/influxdb2 --tag iot-vps && curl -fsS https://your-uptime-kuma-url/api/push/xxxxxThat final curl call is worth highlighting specifically: it pushes a heartbeat to Uptime Kuma, covered in this site’s monitoring guide, confirming the backup actually completed successfully, not merely that the cron job fired. A backup script that silently fails for weeks before anyone notices is arguably worse than having no backup at all, since it creates false confidence rather than an honest, visible gap.
Retention: not keeping every backup forever
restic -r s3:https://your-bucket-endpoint forget
--keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneRestic’s retention policy commands prune older backups according to a sensible schedule, daily backups for the last week, weekly for the last month, monthly for the last six months, a reasonable default balancing genuine recovery flexibility against storage cost growing unbounded.
The part most people skip: actually testing recovery
A backup that’s never been tested isn’t a confirmed backup, it’s an assumption. Periodically, ideally on a schedule rather than only after an actual disaster, running a real restore to a temporary location and confirming the data is genuinely usable, the database actually opens, the configuration actually loads correctly, is the only way to know a backup strategy actually works rather than just looking like it does. This is genuinely the single most commonly skipped step in backup discipline, and the one most likely to matter on the day it’s actually needed.
What to do if total VPS loss happens with no usable backup
Worth having a documented, even if never-needed, rebuild plan: the same guides used to set up MQTT, Node-RED, ThingsBoard and the rest of this site’s stack the first time serve as a rebuild reference, considerably faster than figuring it out from scratch under pressure. Keeping a simple record of any project-specific configuration choices that diverged from this site’s default guides, custom Node-RED flows, specific dashboard layouts, makes this fallback path genuinely viable rather than purely theoretical.
Frequently asked questions
Is it worth paying for a dedicated backup storage service, or can a cheap VPS’s own disk work as a backup target?
A separate VPS’s disk is better than nothing but defeats much of the purpose if it’s hosted with the same provider, since a provider-wide incident could affect both. A genuinely separate, S3-compatible object storage service, often inexpensive for the data volumes involved here, is worth the modest extra cost for real provider independence.
How much storage does a typical IoT VPS’s backup actually need?
Generally modest, configuration files and exported dashboards are small; the main variable is database size, particularly InfluxDB’s telemetry history, where the retention policies covered in this site’s Grafana/InfluxDB guide also indirectly bound how large each backup needs to be.
Should backups be encrypted, even for non-sensitive IoT telemetry?
Yes as a default practice; restic encrypts by default, and there’s little reason to disable it even for data that feels unremarkable, since backup storage is itself an additional location holding a copy of your infrastructure’s configuration and credentials worth protecting consistently.
Does Docker change how backups should be approached?
Mainly in which paths matter, Docker volumes (covered in this site’s Docker guide) typically live under /var/lib/docker/volumes/, worth including explicitly in a restic backup command rather than assuming container data is covered automatically by backing up application directories alone.
How often should a full recovery actually be tested, realistically?
Quarterly is a reasonable, achievable cadence for most projects on this site, frequent enough to catch a broken backup process before it’s been silently failing for too long, without becoming an excessive ongoing time commitment.
Can the same VPS running monitoring also store backups, or should that be separate too?
Worth keeping separate where practical, for the same single-point-of-failure reasoning covered in this site’s monitoring guide; a dedicated, cheap object storage backend for backups specifically, independent of both the live infrastructure and the monitoring VPS, gives the most robust separation for relatively little extra cost.
The realistic cost of getting this wrong
It’s worth being honest about what’s actually at stake in skipping proper backups, since “set up backups eventually” is one of the easiest tasks on any IoT project’s list to keep deferring indefinitely. Losing months of InfluxDB telemetry history means losing exactly the kind of long-term trend data, the gradual solar panel decline, the slow drift in a cold storage unit’s baseline temperature, that this entire site repeatedly argues is the genuine value of self-hosting over a manufacturer’s app in the first place. Losing a carefully tuned Node-RED flow or ThingsBoard dashboard configuration means real hours of rebuilding work, not just an inconvenience. None of this is catastrophic in the way losing a business’s financial records would be, but it’s substantial enough that treating backups as optional, rather than as load-bearing infrastructure on the same level as the services covered throughout this site’s other guides, is a genuine, avoidable risk.
A minimal starting point if the full setup feels like too much at once
For anyone reading this guide and feeling the full layered approach is more than they’re ready to set up immediately, a genuinely useful minimum viable version: a single weekly restic backup of just the configuration files and database directories, to any S3-compatible storage, with no retention policy sophistication and no automated verification yet. This is meaningfully better than nothing, and considerably easier to actually start today than the complete picture covered earlier in this guide, with the rest of the layered approach, automation, verification, a second monitoring VPS, addable incrementally once that first basic backup is genuinely running.
Frequently asked questions
Is it worth paying for dedicated backup storage rather than using the same VPS’s own disk?
A second VPS’s disk is better than nothing but defeats much of the purpose if it’s the same provider. A genuinely separate S3-compatible object storage service, often inexpensive for the data volumes involved, is worth the modest extra cost for real provider independence.
How much storage does a typical IoT VPS backup actually need?
Generally modest — configuration files and exported dashboards are small. The main variable is database size, particularly InfluxDB’s telemetry history, where the retention policies covered in the Grafana/InfluxDB guide also bound how large each backup needs to be.
Should backups be encrypted, even for non-sensitive IoT telemetry?
Yes as a default practice. Restic encrypts by default, and there’s little reason to disable it even for data that feels unremarkable, since backup storage is itself an additional location holding a copy of your infrastructure’s configuration and credentials.
Does Docker change how backups should be approached?
Mainly in which paths matter: Docker volumes typically live under /var/lib/docker/volumes/, worth including explicitly in a restic backup command rather than assuming container data is covered automatically by backing up application directories alone.
How often should a full recovery actually be tested?
Quarterly is a reasonable, achievable cadence for most projects on this site, frequent enough to catch a broken backup process before it’s been silently failing for too long, without becoming an excessive ongoing time commitment.
Can monitoring and backup storage share the same second VPS?
Worth keeping separate where practical, for the same single-point-of-failure reasoning covered in this site’s monitoring guide; a dedicated object storage backend for backups, independent of both the live infrastructure and the monitoring VPS, gives the most robust separation for relatively little extra cost.
Building backup verification into the monitoring stack
The single most impactful addition to a basic restic setup is connecting backup completion to Uptime Kuma via a push/heartbeat monitor, covered in VPS Uptime for 24/7 IoT Operations. A backup script that finishes by calling Uptime Kuma’s push URL, and where Uptime Kuma alerts if no push arrives within 25 hours, transforms backup monitoring from a manual “I should probably check if that ran” to an automatic “I got no alert, so it ran.” This is genuinely the most common improvement worth making to an existing basic backup setup: not more sophisticated retention policies or better compression, but simply making a failure to run visible rather than silent.
Database-specific considerations
For the databases this site’s guides deploy, InfluxDB and PostgreSQL (used by ThingsBoard and ChirpStack), a live filesystem backup of the data directory while the database is running risks creating a corrupt backup if a write is interrupted mid-copy. The correct approach for each differs slightly: InfluxDB 2.x provides a built-in backup command (influx backup) that produces a consistent snapshot; PostgreSQL uses pg_dump for a consistent logical export. Running these commands first, then backing up their output with restic, produces reliable, consistent backups rather than risking a corrupted database directory copy. Adding these commands to the cron job before the restic call, and confirming their output exists before restic runs, is worth a few extra lines of script and catches the single most common backup corruption source before it matters.
What “3-2-1” means in practice for this site’s projects
The 3-2-1 rule, three copies of data, on two different media types, with one copy offsite, is the established starting point for backup thinking. Translated to a typical project on this site: the live VPS is copy one; a provider snapshot is copy two on the same provider’s storage infrastructure; a restic backup to a separate object storage service is copy three in a genuinely different location and on different infrastructure. This isn’t an elaborate, expensive setup: the VPS is already running for other reasons, provider snapshots are typically a small monthly addition, and a modest object storage bucket for a few gigabytes of configuration and database exports costs pennies per month. The 3-2-1 posture is achievable here without significant additional cost or complexity.