Re: Backup/restore recipe

Hello and thanks to everyone for the suggestions.

Overall, making backups is indeed pretty straightforward using ZFS or an 
assortment of "agnostic" filetree-based backup solutions. And in the 
latter case, selective restore is also easy.

What I do not understand is how should one approach restore in scenarios 
2 and 3 (and how to stage the backups for them).

    - selective restore of specific files or subtrees to a working
    FreeBSD system (this one is reasonably obvious)
    - (essentially) exact duplicate of the original system state on the
    same or different machine (ideally binary exact if hardware allows,
    i.e., an equivalent of a cloned server snapshot)
    - functionally equivalent duplicate (i.e., the same filesystem
    content over the potentially different low-level layouts)
    In cases 2 and 3, we likely will have to start from a clean machine,
    possibly with dummy Linux or FreeBSD installation.

Eugene

On 12.11.2025 21:50, Matthias Petermann wrote:
> I’ve had very good experiences using restic for backups on FreeBSD 
> (and other platforms). It’s not tied to ZFS, but for me it’s the best 
> overall compromise between platform independence, snapshot-based 
> versioning, integrity, and security by default.
>
> Backups can be stored locally or across different cloud backends - 
> restic supports all major targets via rclone, so you can use S3, 
> Google Cloud, SMB shares, and more, all with the same workflow.
>
> Restores are fast and flexible - from single files up to full 
> directory trees - and it integrates easily into automated setups (cron 
> jobs, systemd timers, or shell scripts).
>
> A bare-metal restore isn’t supported directly, but with good 
> documentation of your system layout (partitions, ZFS datasets, boot 
> config, etc.) or some deployment automation, that’s easy to work 
> around. I typically treat the system setup as code and use restic for 
> all the actual data.
>
>
> Best regards
> Matthias
>
>
>