Re: Backup/restore recipe

On 13/11/2025 20:28, Frank Leonhardt wrote:
> 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 :-)
>
**** WARNING ****

Actually, don't do it exactly like this. I remembered overnight about 
the trouble I'd had with overlapping mountpoints when I did this a few 
years ago. You can certainly get an exact copy of all the datasets this 
way but there's a catch-22 on booting. If you have the auto mount 
disabled (as above) then it won't boot. If you enable it it will overlay 
the system on the backup server. It can be resolved by booting off 
something else (USB), flipping the switch and then removing the (USB) 
drive and rebooting before it goes too wonky. Then you have a bootable 
disk. It would probably work if the system on the backup and live server 
was the same.

What I do in practice is run everything live in jails anyway, which 
means that other than a few odd files to set up the network (rc.conf and 
jail.conf) you just plonk the jails on top a standard base system. You 
can replicate the whole lot, as I said, but making it bootable isn't clean.