The Handbook

    Theme
    • Guides
        • Check a system before installing FreeBSD
        • Orient a Linux administrator on FreeBSD
        • Supported FreeBSD releases
        • Choose a FreeBSD documentation and support channel
        • Move files safely without GNU mv -t
        • Update, upgrade, or update packages?
        • Upgrade 14.4 or 15.0 to FreeBSD 15.1
        • Choose packages, ports, or poudriere
        • Choose the quarterly or latest package branch
        • Choose a FreeBSD download or package mirror
        • Make a system setting persistent
        • Configure locale, keyboard, and time zone
        • Configure a serial console for recovery
        • Choose a custom kernel, module, or loader setting
        • Run a Linux binary with the compatibility layer
        • Check desktop and laptop hardware before installation
        • Choose and check a graphics driver
        • Choose Xorg or Wayland
        • Build a maintainable desktop baseline
        • Install and check a desktop browser
        • Check laptop Wi-Fi, power, and suspend
        • Check multimedia readiness
        • Choose and configure a printing stack
        • Run Windows applications with Wine
        • Snapshot and replicate a ZFS dataset
        • Choose a filesystem and storage layout
        • Operate ZFS without losing the recovery path
        • Restore files from a ZFS snapshot
        • Read ZFS pool health and run a scrub
        • Replace a failed device in a ZFS mirror
        • Replicate a ZFS dataset over SSH
        • Change PF safely on a remote host
        • Configure a narrow WireGuard tunnel
        • Plan a FreeBSD home server
        • Choose a mail server or an outgoing relay
        • Publish a network service safely
        • Choose a jail network model
        • Choose native jails or a jail manager
        • Choose a jail or a bhyve virtual machine
        • Establish a FreeBSD security baseline
        • Choose a MAC policy
        • Audit security-relevant activity
        • Start a DTrace performance investigation
    • Integrations
        • Create a first jail with Bastille
        • Compare jail managers and OCI tooling
        • Publish a Bastille service through PF
        • Mount a ZFS dataset in a Bastille jail
        • Update and upgrade Bastille jails
        • Back up and restore a Bastille jail
        • Prepare bhyve and vm-bhyve
        • Choose NFS or Samba for file sharing
        • Choose ZFS backup automation
        • Operate a signed poudriere repository
        • Manage FreeBSD configuration with Ansible or Salt
        • Run Motion with webcamd on FreeBSD
        • Design a reverse proxy, certificates, and monitoring
    • FAQ
      • Troubleshooting
          • Recover an interrupted freebsd-update run
          • Resolve a package repository or ABI mismatch
          • Diagnose the FreeBSD boot path
          • Recover with a ZFS boot environment
          • Diagnose DNS, routing, and firewall paths
          • Diagnose network mbuf exhaustion
          • Bind a service to a low port without running it as root
          • Diagnose audio output or input
          • Diagnose webcamd, cuse, and a webcam
          • Fix USB device permissions without opening every device
      • About this handbook
      • Synopsis
      • Inventory everything the service needs
      • Create a consistent export
      • Store the complete recovery set elsewhere
      • Prove restoration on an isolated target
      • Define retention by recoverability
      • Primary references

      Back up and restore a Bastille jail

      Last reviewed
      13 August 2026
      Applies to
      15.1-RELEASE, 15.0-RELEASE, 14.4-RELEASE

      Synopsis #

      bastille export produces an archive or ZFS image that bastille import can restore. That artifact is only one part of a jail backup. Host firewall rules, DNS, secrets held outside the jail, and separately mounted datasets need their own records and backups.

      The safest general export stops the application and jail first. Bastille can export a running ZFS-backed jail, but a storage snapshot alone does not guarantee application consistency.

      Inventory everything the service needs #

      Record the jail, release, network, redirections, mounts, packages, and enabled services:

      # bastille list all
      # bastille rdr web list
      # bastille cmd web mount
      # bastille cmd web pkg info
      # bastille cmd web service -e
      

      Inspect the jail’s fstab and identify every source path outside the managed jail root:

      # less /usr/local/bastille/jails/web/fstab
      

      A dataset added through Mount a ZFS dataset in a Bastille jail is not made safe merely because the jail root is exported. Replicate that dataset separately with Snapshot and replicate a ZFS dataset .

      Create a consistent export #

      Stop or quiesce the application according to its own backup procedure. Then stop and export the jail to a backup filesystem with adequate space. For ZFS-backed Bastille storage:

      # bastille stop web
      # bastille export --xz web /var/backups/bastille
      

      For UFS-backed Bastille storage, use an archive format instead:

      # bastille stop web
      # bastille export --txz web /var/backups/bastille
      

      UFS-backed jails must be stopped for export. ZFS-backed jails support live exports, but use that option only after defining the application’s consistency guarantee. The optional path and resulting filename follow the installed Bastille version; confirm the destination printed by the command before restarting the application.

      Find the resulting artifact, record its size, and create a checksum:

      $ ls -lh /var/backups/bastille
      # sha256 /var/backups/bastille/WEB-EXPORT-FILE > /var/backups/bastille/WEB-EXPORT-FILE.sha256
      

      Replace WEB-EXPORT-FILE with the exact generated filename. Do not use a wildcard in an unattended checksum or transfer command.

      Restart the original jail and verify its service:

      # bastille start web
      # bastille service web nginx status
      

      Store the complete recovery set elsewhere #

      Copy the following to another failure domain:

      • the Bastille export and its checksum;
      • replicated application datasets;
      • the relevant PF and DNS configuration;
      • a record of release, architecture, Bastille version, network mode, and mappings;
      • encrypted application secrets and the separate material needed to decrypt them.

      An export stored under the same pool and host is a staging artifact, not a disaster-recovery copy.

      Prove restoration on an isolated target #

      Prepare a compatible FreeBSD host and Bastille storage. Confirm that no jail with the exported name exists, copy the archive locally, calculate its checksum, and compare the complete digest with the protected record from the source host:

      # sha256 /var/backups/bastille/WEB-EXPORT-FILE
      # bastille list jail
      # bastille import /var/backups/bastille/WEB-EXPORT-FILE
      

      Do not use --force to bypass checksum validation as a normal restore step. If the import needs an explicit release, use the RELEASE argument documented by the installed Bastille version.

      Keep the restored jail isolated until its address and redirections have been reviewed. Restore separately mounted datasets to a deliberate destination, confirm numeric ownership, and update the jail fstab before starting the application.

      Verify the recovered state without immediately publishing it:

      # bastille list all
      # bastille cmd web freebsd-version
      # bastille cmd web pkg check -d
      # bastille cmd web service -e
      # bastille cmd web mount
      

      Only after the local service works should Publish a Bastille service through PF be applied to the recovered host.

      Define retention by recoverability #

      Retain at least one known-good export from before an upgrade and multiple independent recovery points for application data. Monitor backup age, transfer failures, destination capacity, and restore-test results. A backup job that exits successfully but has never been imported does not establish recoverability.

      Primary references #

      • Bastille export command
      • Bastille import command
      • Bastille migrate command
      • sha256(1)

      Independent documentation. Not affiliated with or endorsed by the FreeBSD Project or the FreeBSD Foundation.

      Report a bug
      • Synopsis
      • Inventory everything the service needs
      • Create a consistent export
      • Store the complete recovery set elsewhere
      • Prove restoration on an isolated target
      • Define retention by recoverability
      • Primary references