Backup/Failover Prep for USB OS Firewall

[daemonbak]

Hi all,

I have my firewall running off a flash drive 16gigs.
I want to have a second flash drive on standby incase this one dies.

Which would be the best way to prep a secondary flash drive to throw in the firewall if the original gives up the ghost.

Caveats, I will be moving from a 16gig flash drive to a 32gig flash drive.
Both are from different vendors. So clearly, the partitions will not match size.

I would like this to be a flash drive that is ready to pop in if the drive dies. Once it is set up, I could rsync the drives every so often to account for config changes. Obviously I would not clone fstab because of guids.

Thansk all!

[jggimi]

Your backup drive will need to be bootable. See installboot(8).

After that, you can use any method you wish to synchronize your running system with your backup device. You must consider open files, and the impact of any data loss. Consider including log rotations and other application-specific steps (such as database backup) as a component of your synchronization procedures. How frequently you decide to synchronize is dependent upon the type and amount of data loss you consider acceptable.

I use a pair of firewalls and carp(4), so only need to synchronize select files manually, when changing configurations.

[daemonbak]

Before I I was able to get a back up solution, my system halted with iO errors. The Var partition is having issues and I'm getting FSC K_FFS mornings. I can keep the system running with a F sCK and reboot, However it will run for a few hours at best. The log directly has disappeared so that is causing issues as well.

I redid the partitioning And set up on a new flash drive, but this time I don't want to be down in an emergency. What Will be the best way to duplicate this drive so that I can go back to this point in time if this new flash drive decides to act up. I don't want a running back up like carp, I just want a flash drive that I can throw him in emergency and be back up and running. Obviously as errata is released I would update the emergency copy again. As far as other files, most are static, I would assume that the blacklist would be out of sync but that is more acceptable than staying up till 6am building a new system. This time I used an old Sandisk 32gig drive and will order duplicates to clone the work done tonight. Not feeing warm and fuzzy with the flash drive stability.

Any comments advice warnings anything?

Thanks

[jggimi]

Sorry you are having trouble. There are many choices for backup. And from your description, its not clear if you have two drives in one system, or if your backup needs to occur over a network.

Note: OpenBSD has a built-in altroot facility, designed to replicate the root filesystem when you have two drives on the same system. It uses dd(1), and is documented in the daily(8) man page and FAQ 14.

---

I don't know if you can attach two drives to the same system or not, so this "howto" shows a backup over a network with ssh(1). If the drives are attached to the same system, feel free to eliminate the network file transfers. The user doing the backup needs to have read access to all filesystems, such as granted by the operator class. It is assumed that the userid on the receiving system is using a public/private key pair for authentication, without a passphrase, so that the backup can be scripted.

Open files will NOT be cleanly backed up. As discussed earlier, any databases should be backed up to flat files, any log files should by cycled, etc.

I've chosen dump(8)/restore(8) as these are FFS file systems, and you won't have to worry about file path lengths, device nodes or other special files. TCP socket files don't get copied, but any of those in /var/run will be recreated anyway.

The backup script uses dump level 0 - a full backup. Obviously, you may use different levels for incremental or differential backups on subsequent backups. Run something like this for every filesystem. The example compresses a level 0 dump of /usr and stores it on my.server, in the $HOME directory of user "backup".

$ dump -0af - /usr | gzip | ssh backup@my.server "cat > usr.dump.gz"

However often you need to, you can restore these compressed dump files to FFS filesystems on your server. All you need do is newfs(8) an empty filesystem, mount it, cd to it, and run restore(8). Assuming you don't have incremental backups to apply after restoring a full backup, you can delete the restoresymtable file.

# newfs sd3j
# mount -o async,noatime /dev/sd3j /mnt
# cd /mnt
# gzcat /home/backup/usr.dump.gz | restore -rf -
# rm restoresymtable
# cd
# umount /mnt

As I mentioned, you need to create boot blocks on this spare drive. Assuming, as in the example above, that the drive is sd3, and that the MBR partition table has flagged the OpenBSD partition as active (bootable):

# mount /dev/sd3a /mnt
# installboot -v -r /mnt sd3 /usr/mdec/biosboot /usr/mdec/boot

The bootblocks will need to be reinstalled every time the /boot file -- the second stage bootloader -- moves position in the filesystem.

[jggimi]

I'll add that there are many ways to maintain synchronization between primary and backup systems. net/rsync is often used.