<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Backups on StackNotes</title><link>https://stacknotes.co.uk/categories/backups/</link><description>Recent content in Backups on StackNotes</description><generator>Hugo</generator><language>en-GB</language><lastBuildDate>Sat, 07 Nov 2026 14:10:00 +0000</lastBuildDate><atom:link href="https://stacknotes.co.uk/categories/backups/index.xml" rel="self" type="application/rss+xml"/><item><title>Vaultwarden backup and restore: the 250 KB file that restores an empty vault</title><link>https://stacknotes.co.uk/articles/vaultwarden-backup-and-restore/</link><pubDate>Sat, 07 Nov 2026 14:10:00 +0000</pubDate><guid>https://stacknotes.co.uk/articles/vaultwarden-backup-and-restore/</guid><description>&lt;p&gt;&lt;em&gt;The short version: Vaultwarden runs SQLite in WAL mode, so db.sqlite3 on its own can be almost empty while the instance works perfectly. Copy db.sqlite3 together with db.sqlite3-wal, or take an online backup through SQLite and check that the copy contains users. Take attachments/ and rsa_key.pem as well. Then restore the backup somewhere and log in, because a backup nobody has opened is a rumour.&lt;/em&gt;&lt;/p&gt;&#10;&lt;p&gt;My password manager is a container on the same box as everything else, which means one bad backup script stands between me and a very annoying afternoon. I have written about backing up databases before, and I thought I knew the shape of this one: one SQLite file, one attachment folder, one key. Then I drilled it properly and the first restore came back empty.&lt;/p&gt;</description></item><item><title>Immich backup to an external drive, properly</title><link>https://stacknotes.co.uk/articles/immich-backup-to-external-drive/</link><pubDate>Fri, 06 Nov 2026 23:06:00 +0000</pubDate><guid>https://stacknotes.co.uk/articles/immich-backup-to-external-drive/</guid><description>&lt;p&gt;&lt;em&gt;The short version: the photos are the easy half. Dump Postgres, back up the upload folder to a disk that is not your array, and restore both halves in a drill. A folder of JPEGs on its own is not an Immich backup.&lt;/em&gt;&lt;/p&gt;&#10;&lt;p&gt;Your Immich library is probably the largest thing you own that you cannot download again. It is also the one where a file-level copy feels like it should be enough, because the files are just photos. They are. The library is not.&lt;/p&gt;</description></item><item><title>The self-hosted backup stack that actually restores</title><link>https://stacknotes.co.uk/articles/self-hosted-backup-stack/</link><pubDate>Fri, 06 Nov 2026 21:45:00 +0000</pubDate><guid>https://stacknotes.co.uk/articles/self-hosted-backup-stack/</guid><description>&lt;p&gt;&lt;em&gt;The short version: dump the databases, back up with restic, verify the bytes you wrote, and drill a restore every month. Every number below comes from a run on my own machine.&lt;/em&gt;&lt;/p&gt;&#10;&lt;p&gt;Five thousand rows in a Vaultwarden-shaped SQLite database. The file that was supposed to contain them: 4,096 bytes.&lt;/p&gt;&#10;&lt;p&gt;Not a corruption bug. SQLite in WAL mode, doing exactly what it is designed to do. The table lived in the write-ahead log, the main &lt;code&gt;db.sqlite3&lt;/code&gt; held almost nothing, and a backup that copies only the main file gets a database with no schema in it. I reproduced the setup on purpose: a SQLite database in WAL mode with 5,000 rows inserted and the connection held open. Then I copied the main database file, the way a naive backup script would, opened the copy, and got this:&lt;/p&gt;</description></item></channel></rss>