New post
This commit is contained in:
parent
0ed1e8b2dc
commit
57f71f2a8e
@ -0,0 +1,67 @@
|
||||
---
|
||||
layout: default
|
||||
title: Directly Attache Storage with redundancy and integrity using LVM
|
||||
date: 2023-06-24 20:11 +0200
|
||||
tags: LVM
|
||||
---
|
||||
Directly Attached Storage (DAS) can be effectively used for frequent backups.
|
||||
Risk of data loss can be prevented by means of redundancy and integrity check
|
||||
mechanisms.
|
||||
|
||||
Data on disk can be lost due to:
|
||||
* hardware error correction insufficiency or complete disk failure - which is
|
||||
obvious and can be remedied using multiple copies of same data on multiple
|
||||
disks (RAID). RAID for Logical Volumes is provided by @dm-raid@ kernel module
|
||||
and offers functionality similar to @mdadm@ utility.
|
||||
* silent data corruption - when erros slip through disk's error detection
|
||||
mechanisms and remain undetected. Risk can be considerably reduced by using
|
||||
checksums of data stored on additional integrity sub-LVs using @dm-integrity@
|
||||
module.
|
||||
|
||||
RAID and integrity can be combined: each RAID sub-LV has its per-sector
|
||||
checksums stored on integrity sub-LVs. Whenever checksum mismatch detects silent
|
||||
data corruption, restoration from uncorrupted source is possible thanks to disk
|
||||
redundancy. As of LVM tools 2.03.21 (2023-04-21) detecting which disk holds
|
||||
uncorrputed data would be impossible without @dm-integrity@. Even if
|
||||
3-disk-RAID1 or RAID6 is used - which theoretically is enough to find source of
|
||||
single sector corruption event - the mechanisms are not implemented. See _man
|
||||
lvmraid, "Scrubbing Limitations"_.
|
||||
|
||||
|
||||
h3. Setup
|
||||
|
||||
First create RAID1, then extend it with integrity layer.
|
||||
|
||||
{% highlight bash %}
|
||||
lvcreate --type raid1 --mirrors 1 -n backup -L 4t vgbackup /dev/sda /dev/sdb
|
||||
{% endhighlight %}
|
||||
|
||||
Integrity block size cannot be smaller than drive's logical sector size and
|
||||
preferably should match file system block size.
|
||||
|
||||
{% highlight bash %}
|
||||
$ cat /sys/class/block/sda/queue/physical_block_size
|
||||
4096
|
||||
$ cat /sys/class/block/nvme0n1/queue/logical_block_size
|
||||
512
|
||||
$ lvconvert --raidintegrity y --raidintegrityblocksize 4096 --raidintegritymode bitmap /dev/vgbackup/backup
|
||||
{% endhighlight %}
|
||||
|
||||
Both operations - creating RAID mirror and adding integrity layer - require
|
||||
initial sync, the progress of which can be monitored:
|
||||
|
||||
{% highlight bash %}
|
||||
lvs -a -o name,segtype,devices,sync_percent
|
||||
{% endhighlight %}
|
||||
|
||||
Even before sync is finished, filesystem can be created on LV:
|
||||
|
||||
{% highlight bash %}
|
||||
mkfs.ext4 -b 4096 -O ^has_journal /dev/vgbackup/backup
|
||||
{% endhighlight %}
|
||||
|
||||
and the drives can be detached for later synchronization:
|
||||
|
||||
{% highlight bash %}
|
||||
vgchange -an vgbackup
|
||||
{% endhighlight %}
|
Loading…
x
Reference in New Issue
Block a user