The FreeBSD Boot Process
Let’s talk about the FreeBSD boot process. It is very robust and complex, as it is well-thought. Find out what are the differences when you boot from UEFI or legacy BIOS, or from GPT and MBR partitioning schemes. Learn what happens when you use ZFS or UFS filesystem.
Manipulating a Pool from the Rescue System
We’ve all been there: that moment of panic when a system fails to boot back up. Perhaps there was a glitch with an upgrade. Maybe you’re wondering if you fumble-fingered a typo when you made that last change to loader.conf.
Fortunately, with FreeBSD and its built-in rescue mechanisms it is possible to quickly recover from most scenarios that prevent a system from booting into normal operation. And if you’re using OpenZFS, you can rest assured that your data is intact.
With this article, let’s take a look at some common recovery scenarios.
What Makes a Good Time to Use OpenZFS Slog and When Should You Avoid It
In this article, we’re talking about the OpenZFS SLOG. Find out, among others, about synchronous vs asynchronous writes and the ZIL, why you should use a SLOG and on what type of devices.
Achieving RPO/RTO Objectives with ZFS
Today, let’s talk a little bit less about technology itself, and a little bit more about business management. There are a couple of key management terms that every system administrator and IT professional should know and love—RPO and RTO, or Recovery Point Objective and Recovery Time Objective.
Once we understand the meaning and importance of RTO and RPO, we will take a look at two ZFS technologies—snapshots and replication—which greatly ease their management.
Let’s Talk OpenZFS Snapshots
Understanding which data benefits from being in a snapshot and how long it makes sense to keep snapshots will help you get the most out of OpenZFS snapshots. Pruning snapshots to just the ones you need will make it easier to find the data you want to restore, save disk capacity, and prevent performance bottlenecks on your OpenZFS system.
Managing Boot Environments
A ZFS boot environment is a bootable clone of the datasets needed to boot the operating system. Creating a BE before performing an upgrade provides a low-cost safeguard: if there is a problem with the update, the system can be rebooted back to the point in time before the upgrade.
This article demonstrates how to use the bectl utility to manage BEs and provides examples on how to update packages, apply security patches, and upgrade the operating system using BEs.