Almost nobody self-hosts with no backups at all. The failures that actually cause data loss involve backups that ran successfully every night and turned out to be unrestorable at the one moment it mattered.
Here are the five failure modes, roughly in order of how often they cause real loss.
1. The snapshot is not internally consistent#
Most self-hosted applications keep state in two places: a database, and a directory of files or an object storage bucket. Nextcloud does. GitLab keeps repositories separately from its Postgres database. Most wikis keep attachments outside the document store.
If you back those up as separate jobs, you get two snapshots taken at different moments. Restore them together and the database references files that were not yet written, or files exist with no database row pointing at them. Nextcloud shows entries that error on open. GitLab shows projects whose repositories are missing.
The backup ran. The restore produces a broken application.
What correct looks like: the database dump and the file storage snapshot are taken as one atomic operation, or the application is quiesced for the duration. If the two are taken independently, the pair is not a backup.
2. The secrets are not in the archive#
This one is specific and catches people badly. GitLab encrypts sensitive values - CI/CD variables, deploy tokens, two-factor secrets - with a key stored in a secrets file that lives outside the database.
Back up the database without that file and the archive restores cleanly, appears complete, and every encrypted value in it is permanently unreadable. GitLab's own documentation warns about this, and it still happens constantly.
The same shape appears elsewhere: wiki attachments sitting in object storage whose credentials live in environment variables, or automation tools that encrypt stored credentials with a per-instance key.
What correct looks like: the backup includes the encryption keys, and they are stored somewhere that survives the loss of the instance.
3. Nobody has tested a restore#
A backup you have never restored is a hypothesis. The failure modes above are invisible until you try, which is why they persist for months.
The specific trap is that most backup systems report success on write, not on recoverability. A green dashboard means the archive was uploaded, not that it contains a working application.
What correct looks like: a periodic restore into a throwaway environment, with someone actually opening the application and confirming the data is there. Quarterly is enough for most teams. Never is not.
4. Retention is shorter than your detection time#
Seven days of retention protects you against events you notice within seven days. It does not protect against:
- A migration that silently corrupted a subset of records three weeks ago.
- A user who deleted a project folder last month and only just went looking for it.
- Ransomware that sat dormant before triggering.
If the only clean copy has already rotated out, retention was the failure.
What correct looks like: retention matched to how long problems realistically take to surface. For most business data that is weeks, not days. Longer retention on a lower frequency is a reasonable trade.
5. The backup lives on the machine it protects#
A snapshot on the same disk, or a second volume on the same host, covers accidental deletion and nothing else. It does not cover host failure, filesystem corruption, or a compromise with root access - and an attacker who reaches root will look for backups specifically.
What correct looks like: copies in a separate failure domain, ideally with versioning enabled so an overwrite does not destroy history.
A short self-assessment#
If you run self-hosted applications, five questions:
- Are the database and file storage captured as one consistent snapshot?
- Do the archives include the encryption keys needed to read them?
- When did someone last restore one and open the application?
- Is retention longer than the time it would take you to notice silent corruption?
- Is at least one copy outside the instance's failure domain?
Anything other than a confident yes is a gap worth closing before it is tested for you.
Why this is the strongest argument for managed hosting#
None of this is difficult. It is just detailed, easy to get subtly wrong, and it produces no feedback when done badly - the failure surfaces months later, on your worst day.
That asymmetry is the real case for a managed platform. Not that backups are hard, but that a wrong backup is indistinguishable from a right one until you need it. On VCloud, backups snapshot the database and file storage together, include the material required to decrypt them, and run on retention windows of 7 to 30 days depending on plan.