feat(blog): how LINSTOR and DRBD keep your data alive when a server dies#626
Conversation
Fifth post of the platform series, covering replicated block storage: DRBD synchronous replication, LINSTOR orchestration, storage pool setup, the replicated StorageClass, and node-failure behavior. Facts verified against the v1.5 storage docs. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: tym83 <6355522@gmail.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughChangesReplicated storage blog
Estimated code review effort: 1 (Trivial) | ~3 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content/en/blog/2026-07-22-linstor-drbd-replicated-storage/index.md`:
- Around line 55-73: Update the ZFS storage-pool setup around “Step 2 — Create
storage pools (ZFS)” to configure each created pool with the documented
failmode=continue setting, so DRBD handles disk failures. Apply the setting to
every node’s pool and preserve the existing verification step.
- Around line 86-93: Revise the concluding claims in “What happens when a node
fails” to qualify recovery as applying to a supported single-node failure rather
than guaranteeing uninterrupted, loss-free recovery. Explicitly state that
replication is not a backup and that multiple failures, corruption, or recovery
issues still require backups; avoid promising no manual intervention, restore,
or data loss.
- Around line 75-84: Update the setup instructions before “Step 4 — Use it” to
define or clearly link the required replicated StorageClass, including the
repository-required autoPlace: "3" setting. Ensure users create this
prerequisite before applying application configurations with storageClass:
replicated, while preserving the stated three-replica behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 57d3fc32-c2bd-4feb-935a-c0d813b2bb1c
⛔ Files ignored due to path filters (1)
content/en/blog/2026-07-22-linstor-drbd-replicated-storage/linstor-drbd-replicated-storage.pngis excluded by!**/*.png
📒 Files selected for processing (1)
content/en/blog/2026-07-22-linstor-drbd-replicated-storage/index.md
| **Step 2 — Create storage pools (ZFS):** | ||
|
|
||
| ```bash | ||
| linstor physical-storage create-device-pool \ | ||
| zfs node1 \ | ||
| /dev/nvme0n1 /dev/nvme1n1 \ | ||
| --pool-name data \ | ||
| --storage-pool data | ||
| ``` | ||
|
|
||
| Repeat for each node. | ||
|
|
||
| **Step 3 — Verify:** | ||
|
|
||
| ```bash | ||
| linstor storage-pool list | ||
| ``` | ||
|
|
||
| You should see a `data` pool on each node with available capacity. |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Configure ZFS to let DRBD handle disk failures.
The setup creates ZFS pools but omits zpool set failmode=continue ..., which the repository’s installation documentation recommends so DRBD—not ZFS—handles disk failures. Add this step for every pool or explicitly qualify the failure behavior. (cozystack.io)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@content/en/blog/2026-07-22-linstor-drbd-replicated-storage/index.md` around
lines 55 - 73, Update the ZFS storage-pool setup around “Step 2 — Create storage
pools (ZFS)” to configure each created pool with the documented
failmode=continue setting, so DRBD handles disk failures. Apply the setting to
every node’s pool and preserve the existing verification step.
Source: MCP tools
| **Step 4 — Use it:** | ||
|
|
||
| Any application that specifies `storageClass: replicated` now gets DRBD-replicated volumes (three replicas by default). PostgreSQL, MongoDB, VM disks — all of them. | ||
|
|
||
| ```yaml | ||
| # In any application config: | ||
| values: | ||
| storageClass: replicated | ||
| size: 50Gi | ||
| ``` |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Create the replicated StorageClass before instructing users to consume it.
These steps never define the StorageClass, yet the post says applications can use it and receive three replicas. The repository setup requires creating a StorageClass with autoPlace: "3"; without that prerequisite, a fresh cluster may fail to provision the PVC. Include the manifest or clearly link to the required prerequisite. (cozystack.io)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@content/en/blog/2026-07-22-linstor-drbd-replicated-storage/index.md` around
lines 75 - 84, Update the setup instructions before “Step 4 — Use it” to define
or clearly link the required replicated StorageClass, including the
repository-required autoPlace: "3" setting. Ensure users create this
prerequisite before applying application configurations with storageClass:
replicated, while preserving the stated three-replica behavior.
Source: MCP tools
| ## What happens when a node fails | ||
|
|
||
| 1. DRBD detects the node is gone. | ||
| 2. The volume remains available on the surviving replica node. | ||
| 3. Kubernetes reschedules the pod to a node that has the replica. | ||
| 4. When the failed node comes back, DRBD automatically resyncs. | ||
|
|
||
| No manual intervention. No restore from backup. No data loss. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Do not promise backup-free, loss-free recovery.
A replicated volume can remain available after a supported single-node failure, but “No manual intervention. No restore from backup. No data loss.” is an unsafe absolute guarantee. Qualify this to state the supported failure scenario and explicitly remind operators that replication is not a backup; multiple failures, corruption, or recovery issues still require backups. (cozystack.io)
🧰 Tools
🪛 LanguageTool
[style] ~93-~93: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...l intervention. No restore from backup. No data loss. ## Documentation - [Storag...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@content/en/blog/2026-07-22-linstor-drbd-replicated-storage/index.md` around
lines 86 - 93, Revise the concluding claims in “What happens when a node fails”
to qualify recovery as applying to a supported single-node failure rather than
guaranteeing uninterrupted, loss-free recovery. Explicitly state that
replication is not a backup and that multiple failures, corruption, or recovery
issues still require backups; avoid promising no manual intervention, restore,
or data loss.
Source: MCP tools
Summary
New blog post about replicated block storage in Cozystack: LINSTOR + DRBD.
What
replicatedStorageClass, and node-failure behaviorimages:front matter for link previewsWhy
Continues the platform series (previous: network isolation between tenants). Storage is one of the most common questions from bare-metal operators evaluating Cozystack.
Preview
Netlify deploy preview:
/blog/2026/07/linstor-drbd-replicated-storage/Summary by CodeRabbit