<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Articles on StackNotes</title><link>https://stacknotes.co.uk/articles/</link><description>Recent content in Articles 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/articles/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>Unraid Docker service failed to start: the line that names your cause</title><link>https://stacknotes.co.uk/articles/unraid-docker-service-failed-to-start/</link><pubDate>Sat, 07 Nov 2026 12:10:00 +0000</pubDate><guid>https://stacknotes.co.uk/articles/unraid-docker-service-failed-to-start/</guid><description>&lt;p&gt;&lt;em&gt;The short version: &amp;ldquo;Docker service failed to start&amp;rdquo; means dockerd exited, and it says why on the way out. One line, in its own log. Find that line, match it to one of the seven cases below, and you know whether to grow the image, rebuild it, or fix a file. Deleting the image is the fourth thing to try, not the first.&lt;/em&gt;&lt;/p&gt;&#10;&lt;p&gt;I am writing this from inside a container on an Unraid box, which is an odd place to sit while writing about Docker refusing to start. The filesystem under my feet is a btrfs subvolume inside &lt;code&gt;/mnt/cache/system/docker/docker.img&lt;/code&gt;, a 150 GB image on &lt;code&gt;/dev/loop2&lt;/code&gt; with 31 GB used. When that image has a bad day, my root filesystem goes with it.&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>