Making spare/backup USB sticks
-
I have been using dd to make backup copies my bootable/running USB stick of pfSense for years. Last night, I made a copy of 2.2.5 and it will not boot. It tries to mount / from /dev/ufsid/######12345. I have never seen this before. I have always been booting from /dev/da0s1a. The ufsid number it tries to boot from matches the one from the original USB stick. So I try to change it to the one that this instance of pfSense labels the USB /dev/ufsid/#####0987 and it will not boot. Did something change in 2.2.5?
-
If the backup device is smaller than the source device it may be truncated.
-
Both 16GB, they are different types so I guess they could be a few megabytes off, however dd did not report any issues. Now that you mention it, all of the ones I have done in the past were 4 or 8GB. Is something special about going above 8GB? Any idea why it is referencing /dev/ufsid/#### instead of /dev/da0s1a?
-
Suggestion: stop using dd! Why don't you just install pfSense properly and restore the configuration backup? Dunno where this dd backup "method" comes from.
-
There are many reasons to have a quick simple way to have spare pfSense backups since I have had quite a few USB sticks loose their cookies. The main one is so my wife can just replace a dead one while I am out of town. The question remains why did something I have been using for years suddenly quit. Yes there are other ways to achieve the same result, just trying to understand what is going on.
-
I use this script (attached) for making USB media backups.
Globally replace /vvar in DevDup.sh with the path.
-
There are many reasons to have a quick simple way to have spare pfSense backups since I have had quite a few USB sticks loose their cookies.
Yes, there are many reason to have a backup. There are zero reasons to make backups by using completely broken methods like trying to dd a live system. Absolutely horrible idea leading to inconsistent state and broken filesystem.