Clear guidance for operators protecting Linux servers, Docker stacks, databases, and restic repositories—without pretending a green check is the same as a tested restore.
Page 4 of 6 · 50 guides
S3 Versioning, Object Lock, and append-only access protect restic repositories against different deletion risks. Learn how each affects pruning, storage growth, and the restore procedure you must test.
Use Droplet Backups for recurring whole-server recovery, Snapshots for deliberate Droplet or Volume checkpoints, and application-aware backups when database consistency, finer-grained restores, or an independent recovery
Choose a restic interface by where it runs, what data it can reach, and whether your team can restore without it. Compare three operating models, then run an isolated recovery test.
VPS snapshots can speed up whole-server recovery, but a live disk image does not automatically provide database consistency, complete volume coverage, or point-in-time recovery. Learn when an image is sufficient, what to
Backup scope is a recovery decision, not a checkbox. The meaning of “all databases” changes across PostgreSQL, MySQL, and MongoDB, as do the privileges and blast radius.
Choose a MariaDB backup by the restore you need. Check storage engines and object coverage, use MariaDB-compatible clients, and test a logical or physical restore before relying on MySQL-era assumptions.
pg_dump protects one database; pg_dumpall covers the cluster and global objects. The restore path is different enough to decide up front.
A single-database mongodump can overlap live writes and still lack one point-in-time boundary. This workflow makes that limitation explicit and tests the archive safely.
A restic repository needs permission to locate and list its bucket prefix, read existing repository data, write new backup objects, and delete objects for locks and pruning. Scope those permissions to one bucket and one,