Full backup and restore with dd

[demux]

Pete's answer made me sit up and take notice:

https://forum.netgate.com/topic/180271/23-01-23-05-upgrade-failed/51

A pfSense 23.05 is running here and there is a completely identical computer that should serve as a backup, which should be able to be put into operation really quickly.

To do this, I make a backup using dd after every update to a major release (e.g. now to 23.05). In addition, daily backups of the configuration are made.

In an emergency, the recovery should run in such a way that the dd backup is copied to the replacement computer using dd, and the most up-to-date, regularly saved configuration is imported. And done.

Now I asked myself whether the registration and the hardware IDs could thwart my plans.

I've planned not to worry about adjusting the old IDs in an emergency, but simply to provide the restored installation with a new registration key as soon as the dd backup or the config has been imported.

Should I be able to return to the old computer at some point, Netgate should be able to recognize it again.

Does it work like that or will it fly in my face in an emergency? I really couldn't use that at the time.

Thank you!

[jimp]

It may run but it wouldn't get packages or upgrades without its own proper registration and so on.

We have never recommended that style of full disk "backup" -- it's horribly inefficient and prone to error.

If you need HA, use proper HA. Cold spares are perpetually outdated and problematic.

[demux]

@jimp This the result of a horrible installation experience with Intel i226 network. Had to buy 4 usb lan adapters to install and then upgrade to plus. Maybe this will change with 2.7.0 when released. But it seems to work for now. Yes, I know it's far from elegant.

Why don't you offer boot images for plus series?

[rcoleman-netgate]

@demux said in Full backup and restore with dd:

Why don't you offer boot images for plus series?

It's being worked on.

[w0w]

@demux
What prevents you from using the boot environment function built into the plus version? ZFS snapshots will be better than cloning disks, they are, in fact, instantaneous and available in almost all cases of failure.

[demux]

@w0w Only in case of hardware failures. For all others cases, snapshots are great.

[w0w]

@demux
This is what I have been used several years

<command>/usr/local/bin/bash -c '/sbin/zfs destroy -r zroot@weekbckp &amp;&amp; /sbin/zfs snapshot -r zroot@weekbckp &amp;&amp; /sbin/zfs send -R zroot@weekbckp | /usr/bin/gzip &gt; /root/backup/weekbckp.gz &amp;&amp; /usr/local/bin/curl --upload-file /root/backup/weekbckp.gz ftp://pf@192.168.77.3 &amp;&amp; /bin/rm /root/backup/weekbckp.gz'</command>

This one cron command destroys snapshot if it already exists, creates new one and uploads it to remote ftp...
But you are bound to face pain in the ass during recovery... maybe. I don’t remember exactly how and what, but the disk must already be pre-formatted with ZFS. To be able to restore the snapshot. Maybe for a specialist it is not difficult at all ... but it was given to me only after reading the documentation many times :)

[demux]

@w0w said in Full backup and restore with dd:

But you are bound to face pain in the ass during recovery... maybe.

Such an event normally goes like this

<panic_mode>
<say>FCK!</say>
<say>@%&!#_:%!!!</say>
<create>even more panic</create>
<stress_level>6396</stress_level>
<stress_level_max>7000</stress_level_max>
<coffee>yes</coffee>
<cigarette>yes</cigarette>
<beer>not yet</beer>
<vodka>NOT YET!</vodka>
<find_backups>hmmm... ... success</find_backups>
<get_nervous>yes, please</get_nervous>
<no_internet>f*ck</no_internet>
<what_works>nearly nothing</what_works>
...
</panic_mode>

I prefer things that I can handle very easily in such moments.

[stephenw10]

Mmmm standby hardware is a comforting thing to have in such moments IMO. Yes it will always be slightly behind whatever the failed unit was but as long as it's kept vaguely current you can always update it and restore the current config to it. I have done that myself in exactly this situation.
But, yes, the NDI will be different so both boxes would need to be registered ideally.