Announcement

New LTS for FreeBSD is now available in an initial release  Learn More

Klara
Emergency Help

Get Started

The Challenge

OpenZFS pools change after they go into production. Datasets get added, tunables get copied from forum posts, snapshot schedules run without pruning, and replication reports success whether or not a restore would work. Some early choices, like ashift and vdev layout, cannot be changed without rebuilding the pool. None of this shows up on a dashboard until a resilver, a full pool or a failed restore exposes it.

Keep Your OpenZFS Healthy With Klara’s
Quarterly ZFS Health Check

Each quarter, a Klara engineer reviews four areas of your pools: layout and capacity, snapshot and replication protection, tunables and versions, and recovery. We check ashift and vdev layout against the workload, fill level and free space fragmentation, special vdev sizing, holds on the snapshots your recovery depends on, replication lag, encryption keys on the target, every locally set property, and the date of your last tested restore. You get written findings, ranked by risk, with the fix for each one.

Fewer Surprises

Problems that build slowly, like a pool filling past the point where allocation slows or a snapshot count that only grows, get caught at the next review instead of during an incident.

Proven Recovery

Every review records when you last restored from your replication target and how long it took against your RTO. If there is no date, that becomes the first finding.

Ranked Findings

Every finding is written down and ranked by risk, with the change that fixes it. Your team can work through them, or ask Klara to make the changes.

What does a Quarterly ZFS Health Check cover?

Download the one-page overview. It lists what our engineers review on each pool and what the written findings include.

Download PDF

Still unsure? Let’s Talk!

Our teams have a 72h response time, so you can rest assured someone will reach out to you shortly.

Contact Us