diff --git a/content/posts/lxd-containers-for-human-beings.md b/content/posts/lxd-containers-for-human-beings.md
index 5c7cbb0..504d5c5 100644
--- a/content/posts/lxd-containers-for-human-beings.md
+++ b/content/posts/lxd-containers-for-human-beings.md
@@ -1,7 +1,7 @@
 ---
 title: "LXD: Containers for Human Beings"
 subtitle: "Docker's great and all, but I prefer the workflow of interacting with VMs"
-date: 2023-08-11T16:30:00-04:00
+date: 2023-09-17T18:04:00-04:00
 categories:
   - Technology
 tags:
@@ -186,8 +186,8 @@ The database and webserver might go in _that same_ container.
 [rocky]: https://rockylinux.org/
 
 You treat each container more like you would a VM, but you get the performance
-benefit of _not_ virtualising everything. Containers are _much_ lighter than any
-virtual machine.
+benefit of _not_ virtualising everything. Containers tend to be _much_ lighter
+than most VMs.[^1]
 
 ```kroki {type=d2,d2theme=flagship-terrastruct,d2sketch=true}
 hk: Host kernel
@@ -242,7 +242,7 @@ Application containers also tend to be necessary when the application you want
 to self-host is _only_ distributed as a Docker image and the maintainers
 adamantly refuse to support any other deployment method. This is a _massive_ pet
 peeve of mine; yes, Docker can make running self-hosted applications easier for
-inexperienced individuals,[^1] but application orchestration system _does not_
+inexperienced individuals,[^2] but application orchestration system _does not_
 fit in every single environment. By refusing to provide proper "manual"
 deployment instructions, maintainers of these projects alienate an entire class
 of potential users and it pisses me off.
@@ -257,7 +257,18 @@ interact with it in a similar way to VMs or even your PC; you shell into it,
 `apt install` whatever you need, set up the application, expose it over the
 network (for example, on `0.0.0.0:8080`), proxy it on the container host, and
 that's it! This process can be trivially automated with shell scripts, Ansible
-roles, Chef, Puppet, whatever you like.
+roles, Chef, Puppet, whatever you like. Back the system up using [tarsnap] or
+[rsync.net] or [Backblaze,][bb] Google Drive, and [restic.][restic] If you use
+ZFS for your LXD storage pool, maybe go with [syncoid and sanoid.][ss]
+
+[tarsnap]: https://www.tarsnap.com/
+[rsync.net]: https://rsync.net/
+[bb]: https://www.backblaze.com/
+[restic]: https://restic.net/
+[ss]: https://github.com/jimsalterjrs/sanoid
+
+My point is that using system containers doesn't mean throwing out the last few
+decades of systems knowledge and wisdom.
 
 ## Crash course to LXD
 
@@ -377,5 +388,11 @@ container. If it was set to run at startup, you'll need to recreate the
 container, restore from a backup, revert to a snapshot, etc.
 
 [^1]:
+    There's a [technical
+    publication](https://dl.acm.org/doi/10.1145/3132747.3132763) indicating that
+    specialised VMs with unikernels can be far lighter and more secure than
+    containers.
+
+[^2]:
     Until they need to do _anything_ more complex than pull a newer image. Then
     it's twice as painful as the "manual" method might have been.