expand on known issues with bacula

Closes: team#41474

howto/backup.md

@@ -1706,6 +1706,14 @@ This service is maintained by TPA, mostly by anarcat.
 
 ## Backups
 
+This is the backup service, so it's a bit circular to talk about
+backups. But the Bacula director server *is* backed up to the storage
+server like any other server, [disaster recovery](#disaster-recovery) procedures
+explain how to restore in catastrophic failure cases.
+
+An improvement to the backup setup would be two have two storage
+servers, see [tpo/tpa/team#41557](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41557) for followup.
+
 ## Other documentation
 
  * [upstream manual](https://www.bacula.org/9.4.x-manuals/en/main/index.html) (has formatting problems, the [PDF](https://www.bacula.org/9.4.x-manuals/en/main/main.pdf) looks better)
@@ -1724,13 +1732,43 @@ TODO: populate Discussion section.
 
 ## Security and risk assessment
 
+Bacula is pretty good, security-wise, as it "pulls" backups from
+servers. So even if a server is compromised, an attacker cannot move
+laterally to destroy the backups.
+
+It is, however, vulnerable to a cluster-wide compromise: if, for
+example, the Puppet or Bacula director servers are compromised, all
+backups can be destroyed or tampered with, and there's no clear
+workaround for this problem.
+
+There are concerns about the consistency of backups. During a GitLab
+incident, it was found that some log files couldn't be restored
+properly ([tpo/tpa/team#41474](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41474)). It's unclear what the cause of
+this problem was.
 
 ## Technical debt and next steps
 
+Bacula has been lagging behind upstream, in Debian, where we have been
+stuck with version 9 for three major releases (buster on 9.4 and
+bullseye/bookworm on 9.6). Version 13 was uploaded to unstable in
+January 2024 and may ship with Debian trixie (13). But Bacula 15
+already came out, so it's possible we might lag behind.
 
+Bacula was forked in 2013 into a project called BareOS but that was
+never widely adopted. BareOS is not, for example, packaged in Debian.
 
+We have a significant amount of legacy built on top of Bacula. For
+example, we have our own scheduler, because the Bacula scheduler was
+perceived to be inadequate. It might be worth reconsidering this.
 
+Bacula is old software, designed for when the state of the art in
+backups was tape archival. We do not use tape (see below) and are
+unlikely ever to. This tape-oriented design makes working with normal
+disks a bit awkward.
 
+Bacula doesn't deduplicate between archives the way more modern backup
+software (e.g. Borg, Restic) do, which leads to higher disk usage,
+particularly when keeping longer retention periods.
 
 ## Proposed Solution