Re: [List] Re: Backup/restore recipe

On 13/11/2025 13:20, Frank Leonhardt wrote:
> On 12/11/2025 19:06, Eugene R wrote:
>>
>> 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
>>
> Using ZFS send to replicate the datasets does indeed produce a "binary 
> exact" snapshot for most intents. The blocks might be stored in 
> difference places on the destination but to the rest of the system 
> it's identical. You can copy the datasets onto a pool on a new drive, 
> copy the bootloader on to it, plug it into a server and just boot it 
> back up. If you're replicating the datasets to their own pool. on [a] 
> dedicated drive[s]  you can maintain a ready-to-go clone of the live 
> server.
>
> You can also go into the backup datasets and copy individual files (or 
> whole datasets) out as required. Make sure the backup datasets are set 
> to "read-only" or the act of accessing them
>
> I've seen suggestions for various file level backups, which have their 
> place, but you specifically asked to backup the whole running system. 
> If you replicate a ZFS snapshot you get everything in a way that's not 
> possible when copying individual files from a live system. AIX has 
> this facility in JFS2, but it's not common.
>
> If course, if it's a VM you can take a snapshot of the VMDK and copy 
> that, but it's not actually as good as a ZFS snaphshot guarantees the 
> FS is in a consistent state whereas VMWare has no way of telling if 
> it's mid-way through a TXG. But I use real hardware :-)
>
> Regards, Frank.
>
This is the general idea...

Supposing you have server1 as your live server, and backupserver as your 
backup. I would name the zpools after the server (it's more meaningful 
than zroot and stops clashes). So the live server's root zpool is called 
"server1" and the backup server is called something else.

So on your backup server:

1) Insert your blank "clone" hard disk, say da1.
2) Copy the partition table from server1 (gpart backup). and get this to 
backupserver somehow (e.g. cut/paste is quickest)
3) Copy the partition table to da1 (gpart restore)
4) Copy the boot code to it: gpart bootcode -b /boot/pmbr -p 
/boot/gptzfsboot -i 1 da1
5) Create an empty zpool on da1:  zpool create -o altroot=/mnt -O 
mountpoint=none server1 /dev/da1p2
6) Set the boot file system zpool set bootfs=server1/ROOT/default server1

On the live server:

7) Snapshot the original data on server 1: zfs snapshot -r server1@backup
8) Copy the data: zfs send -R server1@backup | ssh backupserver "zfs 
receive -Fduv server1"

Thereafter you can send snapshot deltas and keep it in sync. I don't 
think I've missed anything, but this should maintain a bootable disk 
that's identical to the one on server1. If I get a moment I'll test it. 
I've done this a few times and wish I'd written it down, but in general 
I'm just preserving the zpool. Setting it up to boot is easy enough. If 
it's a multi-disk setup just have multiple disks on backupserver and 
alter the "zpool create" to match

What you don't want to do is omit the altroot and mountpoint=none stuff 
or you'll end up with two systems mounted on root on the backupserver. 
It's a bit tricky when that happens. So I'm told :-)