Essential Eight on Linux, Part 8 of 8: Regular Backups on Ubuntu 26.04 LTS Source
Markdown source
1---2title: "Essential Eight on Linux, Part 8 of 8: Regular Backups on Ubuntu 26.04 LTS"3date: "2026-05-05"4published: true5tags: ["essential-eight", "asd", "ism", "ubuntu", "linux", "backups", "restic", "zfs", "security"]6author: "Gavin Jackson"7excerpt: "Part 8 of an 8-part series on implementing the Essential Eight on Ubuntu 26.04 LTS, covering regular backups with restic, snapshots, immutable storage, and Linux-first recovery design."8---910# Essential Eight on Linux, Part 8 of 8: Regular Backups on Ubuntu 26.04 LTS1112Regular backups are the least glamorous of the Essential Eight mitigations and one of the most important.1314They are also where Linux teams sometimes get overconfident. Plenty of Ubuntu environments have backups. Fewer have backups that are protected from the same compromise path, regularly tested, and structured to recover whole services rather than just files.1516That difference matters.1718## What ASD is trying to achieve1920The security purpose of the backup mitigation is not just retention. It is recovery under hostile conditions:2122- ransomware23- destructive admin mistakes24- credential compromise25- infrastructure failure2627For Ubuntu 26.04 LTS, the question is not "can I copy the files somewhere?" It is "can I restore the system or service safely and predictably when the primary environment is no longer trustworthy?"2829## Ubuntu 26.04 LTS reference implementation3031### Resolute Raccoon highlights3233There is no single headline backup feature in Resolute Raccoon that changes this mitigation the way Livepatch or authd change other parts of the series.3435The relevant 26.04 improvements are indirect:3637- **TPM-backed full-disk encryption** is generally available in the installer3839That helps protect data on lost or stolen endpoints, but it does not replace backup discipline. Backups still need separate credentials, separate storage, tested restores, and protection from the production environment being compromised.4041### 1. Back up data, configuration, and rebuild context4243For Linux servers, file backup alone is rarely enough.4445You usually need:4647- application data48- system configuration49- secrets management approach50- package and image definitions51- infrastructure-as-code or deployment manifests52- database-consistent backup procedures5354If the restore requires a departed engineer's memory, the control is weaker than it looks.5556> **Rebuild, don't restore**57>58> Not every Linux server needs a traditional file-level backup. If a host has no unique persistent data and can be rebuilt predictably inside the required recovery window, the stronger pattern may be **rebuild, not restore**.59>60> This fits well for things like recursive DNS resolvers, secondary DNS servers where the zone source of truth lives elsewhere, jump hosts, static web servers, reverse proxies, load balancers, caching proxies, NTP servers, CI runners, Kubernetes worker nodes, and container hosts. The practical pattern is **PXE boot plus Ubuntu autoinstall**, followed by **Ansible** or another orchestration tool to apply roles, hardening, monitoring, logging, and application configuration.61>62> The thing you must protect is the source of truth: Git repositories, Ansible inventory, autoinstall data, package mirrors, secrets management, certificates, DNS/IPAM records, and any content or configuration that is not generated automatically. If that source of truth is gone, the server was not really rebuildable.63>64> This lines up with modern container patterns. Stateless workloads should usually be redeployed from known images and configuration, not restored like pets. Persistent volumes, databases, authoritative data, audit logs, and anything users or systems write to over time still need a backup and restore plan.6566### 2. Use native Linux backup tooling that is simple and testable6768Ubuntu works well with tools such as:6970- `restic`71- `borgbackup`72- filesystem snapshots with ZFS, Btrfs, or LVM where appropriate7374For many teams, `restic` or `borgbackup` is a good fit for backing up configuration, user data, small services, and file-based workloads. They are less appropriate as the only backup mechanism for large virtualised server fleets or databases unless you also handle application consistency.7576A practical pattern is:7778- use database-native dumps, WAL shipping, or application-aware backup hooks for stateful services79- use `restic` or `borgbackup` for files, configuration, and smaller workloads80- use hypervisor-aware backup for VM recovery where the Linux server is virtualised81- use orchestration and rebuild testing for genuinely stateless servers82- document which restore path applies to each service8384> **Hard links and cloud paranoia**85>86> I still have a soft spot for two older backup tools: **dirvish** and **tarsnap**.87>88> Dirvish was clever in a very Unix way. It used `rsync` and hard-linked snapshot trees so each backup could look like a full filesystem image without storing a complete duplicate every time. For file-based backups, that was a beautifully practical trick: simple to browse, simple to restore from, and much more space-efficient than it first appeared.89>90> Tarsnap felt ahead of its time when I was working on FreeBSD systems. It offered encrypted, deduplicated, cloud-based backups with a familiar tar-like command line long before "secure cloud backup" felt like a normal infrastructure pattern. It was opinionated, cautious, and very FreeBSD in spirit.91>92> I would not necessarily choose either as the default enterprise pattern for Ubuntu 26.04 today, but the design lessons still hold up: make backups space-efficient, keep restores simple, encrypt before data leaves your control, and do not confuse a clever tool with a tested recovery process.9394### 3. Make backup storage hard to tamper with9596This is where a lot of backup strategies fail under real attack.9798Good Linux backup design should include:99100- separate credentials for backup administration101- immutable or write-once protections where possible102- network separation between production systems and backup control paths103- encryption at rest and in transit104- limited direct access from general administrators105- monitoring for failed jobs, missed schedules, and repository verification failures106107If an attacker can compromise a Linux server and immediately delete or encrypt its backups with the same credentials, you do not really have a resilient control.108109### 4. Snapshot fast, restore deliberately110111Snapshots are useful, especially on Ubuntu systems using ZFS or LVM, but do not confuse snapshots with a full backup strategy.112113Snapshots help with:114115- fast rollback116- point-in-time recovery117- operational mistakes118119But they usually still depend on the same platform or storage domain unless replicated elsewhere.120121### 5. Test service recovery, not just file retrieval122123The meaningful test is not "I restored one file from last Tuesday."124125The meaningful test is more like:126127- can the application be rebuilt?128- can the database be restored consistently?129- can the host or container platform be brought back in order?130- are credentials and dependencies handled safely during recovery?131- does the restore meet the service's recovery time and recovery point expectations?132133That is the difference between backups and recoverability.134135### 6. Remember that many Linux servers are really virtual machines136137In a lot of enterprise environments, "Linux server backup" is really "virtual infrastructure backup with Linux workloads inside it."138139That changes the design conversation a bit.140141If your Ubuntu servers are running on **VMware vSphere**, the backup strategy often needs to cover:142143- image-level VM backup144- application-consistent guest processing where required145- fast whole-VM recovery146- file-level or item-level recovery for targeted cases147- retention and immutability at the backup platform148149For many enterprises, this is where a platform-aware backup product is more realistic than relying purely on in-guest scripts.150151The important caveat is that image-level VM backup is not the same thing as application-consistent backup. For databases and directory services, you still need either guest processing that quiesces the workload correctly or an application-native backup path that you have actually restored from.152153### 7. vSphere patterns: Bareos and Veeam154155If your Linux estate sits mostly on vSphere, two patterns are worth calling out.156157**Bareos** is interesting if you want an open-source oriented backup platform and are comfortable investing engineering effort into the backup stack. It is worth a look for teams that want more control over how backup is built and operated, especially in mixed Linux-heavy environments.158159**Veeam** is the more mainstream enterprise answer. It is widely used in VMware environments for a reason:160161- strong support for vSphere backup and restore162- image-level recovery workflows163- broader enterprise operational maturity164- options such as hardened Linux repositories and immutability165166If I were writing this for a typical enterprise with a large vSphere footprint, I would be very comfortable calling **Veeam** the default commercial reference point.167168### 8. Proxmox VE and Proxmox Backup Server as an open source path169170If the virtualisation stack is **Proxmox VE**, the natural companion is **Proxmox Backup Server (PBS)**.171172That pairing is worth mentioning because it is one of the cleaner open-source infrastructure stories available right now:173174- VM and container aware backups when integrated with Proxmox VE175- deduplication176- encryption and integrity protections177- replication and sync options178- a design that is purpose-built for the Proxmox ecosystem179180I want to be careful here though: I have **not** yet used Proxmox Backup Server directly in anger. It is on my list to evaluate properly in my test environment, because on paper it looks like a very credible open-source option for Proxmox-based virtual estates. I would not position it as a drop-in answer for VMware environments.181182That is exactly the sort of thing a home lab is good for. I wrote more about that here: [Why the Home Lab Still Matters for IT Professionals](/post/importance-of-home-lab-it-professional).183184## ISM control mapping185186The October 2024 Essential Eight to ISM mapping links this mitigation to these controls:187188| ISM control | E8 requirement in plain English | Ubuntu 26.04 implementation |189|-------------|----------------------------------|-----------------------------|190| `ISM-1511` | Backups are performed and retained according to business criticality and continuity requirements. | Define backup scope per service: data, application state, configuration, package/image definitions, secrets handling, and retention. |191| `ISM-1810` | Backups are synchronised so restoration can occur to a common point in time. | Coordinate VM snapshots, database dumps, WAL shipping, and application quiescing so restored components line up. |192| `ISM-1811` | Backups are retained securely and resiliently. | Use separate backup credentials, separated storage, encryption, immutable retention where available, and monitoring for failed jobs. |193| `ISM-1515` | Restoration from backups is tested as part of disaster recovery exercises. | Run restore exercises that rebuild the service, time the restore, and check data consistency. |194| `ISM-1812` | Unprivileged users cannot access backups belonging to other users. | Do not expose backup repositories as shared mounts. Use per-service accounts, ACLs, and restore workflows instead of direct user access. |195| `ISM-1813` | Unprivileged users cannot access their own backups at higher maturity levels. | Avoid user self-service access to raw repositories. Provide controlled restore requests or delegated restore portals. |196| `ISM-1705` | Privileged users, except backup administrators, cannot access backups belonging to other users. | Separate Linux system administration from backup administration. Domain, sudo, or vCenter admin should not automatically grant backup repository access. |197| `ISM-1706` | Privileged users, except backup administrators, cannot access their own backups at higher maturity levels. | Keep privileged recovery through the backup platform workflow rather than direct repository browsing. |198| `ISM-1814` | Unprivileged users are prevented from modifying or deleting backups. | Use append-only repository modes, object lock, retention lock, or storage-side WORM controls where supported. |199| `ISM-1707` | Privileged users, except backup administrators, are prevented from modifying or deleting backups. | Use backup RBAC, separate admin paths, hardened repositories, and storage immutability so ordinary admins cannot destroy backups. |200| `ISM-1708` | Backup administrator accounts are prevented from modifying or deleting backups during the retention period. | Use immutability that is enforced by the repository or storage platform, not just by backup-console permissions. |201202## Where Linux teams should be careful203204Common weak patterns on Ubuntu estates include:205206- backups running with overly broad root credentials207- backup repositories mounted directly into production servers208- no immutability or retention lock209- snapshots mistaken for offline recovery210- no documented owner for application-consistent database recovery211- "rebuildable" servers that still contain hand-edited local configuration212- restore testing skipped because "the job says success"213214None of those survive a serious ransomware event gracefully.215216## Commercial or enterprise-friendly additions217218Linux-native backup tooling is good enough for many environments, so this is not a mitigation where you must rush to a commercial product.219220Still, if you need enterprise orchestration, policy, or broader platform coverage, products such as **Veeam**, **Commvault**, or **Rubrik** are worth evaluating alongside Linux-native tools. In VMware-heavy environments, I would especially call out **Veeam** as a very common and practical answer.221222If open source and platform ownership are stronger priorities, **Bareos** and **Proxmox Backup Server** are also worth looking at, with the important caveat that the fit depends heavily on the hypervisor layer and your willingness to own more of the engineering.223224The important thing is not the brand. It is separation, recoverability, and proof.225226## A practical Ubuntu backup pattern227228For an Ubuntu 26.04 reference design, I would aim for:229230- `restic`, `borgbackup`, or another well-understood Linux backup tool for files and configuration231- database-native backup or application-aware hooks for stateful services232- PXE boot, Ubuntu autoinstall, and Ansible for servers that are genuinely stateless and rebuildable233- protected source-of-truth repositories, inventories, secrets, certificates, and IPAM/DNS records234- hypervisor-aware backup for virtualised Linux servers235- Veeam for enterprise vSphere estates, or Bareos where an open-source oriented stack is a better fit236- Proxmox Backup Server where Proxmox VE is the virtualisation platform237- encrypted backups to object storage or a hardened repository238- immutable retention where the storage platform supports it239- snapshot capability for fast operational recovery240- separate admin paths for backup infrastructure241- regular restore exercises for critical services, including timing the restore and checking data consistency242243That is a much stronger control than a beautifully green dashboard nobody has ever tried to restore from.244245## The bottom line246247Regular backups on Ubuntu 26.04 LTS are not hard to implement. Resilient backups are harder.248249Use Linux-native tooling where it fits, but do not ignore the hypervisor layer if most of your Linux servers are virtual machines. For many enterprises that means a vSphere-aware platform such as Veeam, and for more open-source oriented environments it may mean evaluating Bareos or Proxmox Backup Server. Isolate the backup trust boundary, test restores like they matter, and design for service recovery instead of checkbox retention. That is the version of this Essential Eight mitigation that actually holds up under pressure.250251## References252253- [ASD Essential Eight maturity model and ISM mapping (October 2024)](https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model-and-ism-mapping)254- [Canonical releases Ubuntu 26.04 LTS Resolute Raccoon](https://ubuntu.com/blog/canonical-releases-ubuntu-26-04-lts-resolute-raccoon)255- [Setup a ZFS storage pool](https://ubuntu.com/tutorials/setup-zfs-storage-pool)256- [restic](https://restic.net/)257- [BorgBackup](https://www.borgbackup.org/)258- [Dirvish](https://dirvish.org/)259- [Tarsnap](https://www.tarsnap.com/)260- [Bareos virtual infrastructure backup](https://www.bareos.com/virtual-infrastructure-backup/)261- [Veeam VMware vSphere support](https://helpcenter.veeam.com/docs/vbr/userguide/platform_support_vm.html)262- [Veeam Linux hardened repository](https://helpcenter.veeam.com/docs/vbr/userguide/hardened_repository.html)263- [Proxmox Backup Server](https://www.proxmox.com/en/products/proxmox-backup-server/overview)264- [Proxmox Backup Server documentation](https://pbs.proxmox.com/docs/)265