이것은 내 오프사이트 rsync 백업 서버에 대한 설정입니다.
Ubuntu 20.10, 9개의 하드 드라이브 포함.
디스크 /dev/sd[ah]는 백업 볼륨 그룹에 속합니다.
시스템은 /dev/sdi에 있습니다.
서버는 다음과 같습니다:
- 네트워크 제어 스위치를 통해 전원을 켜십시오(그렇지 않으면 그리드에서 연결이 끊어집니다).
- Wake on LAN 구성됨
- Dropbear가 구성되어 네트워크를 통해 cryptfs를 잠금 해제하고 시스템을 부팅하는 데 사용할 수 있습니다.
초기 LVM LUKS 설정:
cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sda
cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdc
cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdd
cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sde
cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdf
cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdg
cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdh
cryptsetup luksOpen /dev/sda luks_sda
cryptsetup luksOpen /dev/sdb luks_sdb
cryptsetup luksOpen /dev/sdc luks_sdc
cryptsetup luksOpen /dev/sdd luks_sdd
cryptsetup luksOpen /dev/sde luks_sde
cryptsetup luksOpen /dev/sdf luks_sdf
cryptsetup luksOpen /dev/sdg luks_sdg
cryptsetup luksOpen /dev/sdh luks_sdh
pvcreate /dev/mapper/luks_sda
pvcreate /dev/mapper/luks_sdb
pvcreate /dev/mapper/luks_sdc
pvcreate /dev/mapper/luks_sdd
pvcreate /dev/mapper/luks_sde
pvcreate /dev/mapper/luks_sdf
pvcreate /dev/mapper/luks_sdg
pvcreate /dev/mapper/luks_sdh
vgcreate tiburon_backup_vg /dev/mapper/luks_sda
vg를 생성하기 위해 추가 /dev/mapper/luks_sd* 장치를 추가했습니다. 마운트 지점을 사용하여 lv를 생성했습니다.
각 luks_sd*에 대해 /etc/crypttab을 업데이트했습니다.
luks_sd[a-h] /dev/sd[a-h] /etc/luks-keys/luks_sd[a-h] luks
그런 다음 initramfs를 업데이트했습니다.
update-initramfs -uv
reboot
7년 동안은 모든 것이 괜찮았습니다. 지금까지는 불량 섹터가 점점 더 많아지기 때문에 /dev/sdf를 교체해야 했습니다.
5TB의 데이터를 복사하고 데이터를 잃지 않고 진행하는 방법을 잘 모르겠습니다.
데이터 손실을 방지하기 위해 지금까지 내가 찾은 내용은 다음과 같습니다.
cryptsetup status
cryptswap1
luks_sde
Tiburon2--vg-root
luks_sda
luks_sdf #problematic luks disk
Tiburon2--vg-swap_1
luks_sdb
luks_sdg
tiburon_backup_vg-tiburon_backup #problematic vg-lv
luks_sdc
luks_sdh
luks_sdd
sdb5_crypt
cryptsetup status luks_sdf
/dev/mapper/luks_sdf is active and is in use.
type: LUKS1
cipher: aes-xts-plain64
keysize: 512 bits
key location: dm-crypt
device: /dev/sdf
sector size: 512
offset: 4096 sectors
size: 3907025072 sectors
mode: read/write
umount /tiburon_backup
vgchange -a n tiburon_backup_vg
0 logical volume(s) in volume group "tiburon_backup_vg" now active
pvmove /dev/mapper/luks_sdf
Insufficient free space: 476931 extents needed, but only 1 available
Unable to allocate mirror extents for tiburon_backup_vg/pvmove0.
Failed to convert pvmove LV to mirrored.
#Therefore:
e2fsck -f /dev/mapper/tiburon_backup_vg-tiburon_backup
#FS/VG has 8TB, and 4TB is in use, therefore shrinking it to 5TB:
resize2fs -p /dev/mapper/tiburon_backup_vg-tiburon_backup 5T
Początkowy przebieg 2 (maksymalny = 262145)
Relokowanie bloków XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Początkowy przebieg 3 (maksymalny = 40960)
Przeszukiwanie tablicy i-węzłówXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
lvreduce -L 5T /dev/mapper/tiburon_backup_vg-tiburon_backup
WARNING: Reducing active logical volume to 5,00 TiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce tiburon_backup_vg/tiburon_backup? [y/n]: y
Size of logical volume tiburon_backup_vg/tiburon_backup changed from <7,80 TiB (2043653 extents) to 5,00 TiB.
Logical volume tiburon_backup_vg/tiburon_backup successfully resized.
e2fsck -f /dev/mapper/tiburon_backup_vg-tiburon_backup
e2fsck 1.45.6 (20-Mar-2020)
Przebieg 1: Sprawdzanie i-węzłów, bloków i rozmiarów
Przebieg 2: Sprawdzanie struktury katalogów
Przebieg 3: Sprawdzanie łączności katalogów
Przebieg 4: Sprawdzanie liczników odwołań
Przebieg 5: Sprawdzanie sumarycznych informacji o grupach
/dev/mapper/tiburon_backup_vg-tiburon_backup: 11/176128 plików (0.0% nieciągłych), 281453/1408000 bloków
이제 pvscan은 /dev/mapper/luks_sdf가 비어 있음을 보여줍니다.
PV /dev/mapper/luks_sdf VG tiburon_backup_vg lvm2 [<1,82TiB / 1,82TiB 사용 가능]
이제 실행하면 다음과 같습니다.
pvmove /dev/mapper/luks_sdf
해당 PV의 나머지 블록을 vg 내의 다른 사용 가능한 공간에 미러링해야 합니다. 그렇죠? (아니면?)
그 후에는 다음을 수행할 계획입니다.
vgchange -a n tiburon_backup_vg
cryptsetup close luks_sdf
vgreduce tiburon_backup_vg /dev/mapper/luks_sdf
pvremove /dev/sdf
#remove luks_sdf from /etc/crypttab
이것이 작동할까요? 아니면 LUKS의 VM에서 결함이 있는 디스크를 제거하는 더 좋은 방법이 있습니까?
어떤 아이디어라도 주셔서 대단히 감사합니다.
답변1
작업 순서를 약간 수정해야 합니다.
예, pvmove
할당된 블록이 남아 있으면 이 작업이 수행됩니다. 실제로 LVM 데이터가 전혀 없어도 /dev/mapper/luks_sdf
문제가 되지 않습니다 .
성공하면 pvdisplay /dev/mapper/luks_sdf
및 필드에 정확히 동일한 값이 표시되어야 하며 0이어야 합니다.Total PE
Free PE
Allocated PE
이 시점에서는 다음을 수행할 필요가 없습니다. VG에서 제거 vgchange -a n tiburon_backup_vg
하기만 하면 됩니다 vgreduce tiburon_backup_vg /dev/mapper/luks_sdf
(이제 LVM 데이터가 없으므로 온라인으로 수행할 수 있습니다).
LVM이 LUKS 위에 위치하므로 이 작업을 수행하는 것이 중요합니다.앞으로 cryptsetup close luks_sdf
, 왜냐하면 시스템은 /dev/sdf
다음의 암호화된 콘텐츠만 볼 것이기 때문입니다. 그리고 시도하면 pvremove /dev/sdf
제거할 LVM 헤더가 없다는 메시지가 표시됩니다(무의미한 암호화된 데이터만 볼 수 있기 때문입니다).
이 경우 pvremove
실행할 필요가 없습니다. 디스크가 VG에서 제거된 한 LVM은 더 이상 디스크가 존재할 것을 요구하지 않으며 핫 플러그해도 상관하지 않습니다. (하드웨어가 실제로 핫 플러그를 지원하지 않는 경우 핫 플러그를 수행하지 마십시오.)
종료하기 전에 initramfs를 삭제하거나 주석 처리 /dev/sdf
하고 /etc/crypttab
업데이트하는 것을 잊지 마십시오. 그렇지 않으면 시스템이 부팅 시 LUKS를 활성화하려고 시도하고 /dev/sdf
더 이상 디스크를 찾을 수 없기 때문에(또는 새 디스크를 찾을 수 없기 때문에) 패닉 모드로 전환됩니다. 위치에 기존 LUKS 헤더가 없는 디스크).
답변2
이 테스트가 미래의 누군가에게 도움이 되기를 바랍니다.
root@Tiburon3:~# pvscan
PV /dev/mapper/luks_sda VG bck_vg lvm2 [<232.87 GiB / 0 free]
PV /dev/mapper/luks_sdb VG bck_vg lvm2 [<931.50 GiB / 0 free]
PV /dev/mapper/luks_sdc VG bck_vg lvm2 [<1.82 TiB / 0 free]
PV /dev/mapper/luks_sdd VG bck_vg lvm2 [149.03 GiB / 0 free]
PV /dev/mapper/luks_sde VG bck_vg lvm2 [<1.82 TiB / 0 free]
PV /dev/mapper/luks_sdf VG bck_vg lvm2 [<1.82 TiB / 0 free]
PV /dev/mapper/luks_sdg VG bck_vg lvm2 [<931.50 GiB / 0 free]
PV /dev/mapper/luks_sdh VG bck_vg lvm2 [149.03 GiB / 79.83 GiB free]
PV /dev/mapper/sdb5_crypt VG Tiburon3-vg lvm2 [<148.53 GiB / <111.28 GiB free]
Total: 9 [7.94 TiB] / in use: 9 [7.94 TiB] / in no VG: 0 [0 ]
root@Tiburon3:~# df -hP /tiburon_backup/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/bck_vg-lv_tib_bck 7.7T 93M 7.3T 1% /tiburon_backup
#VG의 끝에 도달하려면 FS를 더미 데이터로 채웁니다.
cd /tiburon_backup/
FROMHERE=848
for ((i=FROMHERE; i>=1; i--))
do
fallocate -l 10GB gentoo_root$i.img
done
root@Tiburon3:/tiburon_backup# df -hP /tiburon_backup/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/bck_vg-lv_tib_bck 7.7T 7.3T 20G 100% /tiburon_backup
fallocate -l 10G gentoo_root000.img
root@Tiburon3:/tiburon_backup# pvscan
PV /dev/mapper/luks_sda VG bck_vg lvm2 [<232.87 GiB / 0 free]
PV /dev/mapper/luks_sdb VG bck_vg lvm2 [<931.50 GiB / 0 free]
PV /dev/mapper/luks_sdc VG bck_vg lvm2 [<1.82 TiB / 0 free]
PV /dev/mapper/luks_sdd VG bck_vg lvm2 [149.03 GiB / 0 free]
PV /dev/mapper/luks_sde VG bck_vg lvm2 [<1.82 TiB / 0 free]
PV /dev/mapper/luks_sdf VG bck_vg lvm2 [<1.82 TiB / 0 free]
PV /dev/mapper/luks_sdg VG bck_vg lvm2 [<931.50 GiB / 0 free]
PV /dev/mapper/luks_sdh VG bck_vg lvm2 [149.03 GiB / 79.83 GiB free]
rm -f gentoo_root[1-9]*
root@Tiburon3:/tiburon_backup# df -hP .
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/bck_vg-lv_tib_bck 7.7T 10G 7.3T 1% /tiburon_backup
root@Tiburon3:/tiburon_backup# du -sh *
10G gentoo_root000.img
root@Tiburon3:/#
btrfs filesystem resize -1T /tiburon_backup
Output:
Resize '/tiburon_backup' of '-1T'
빈 파일 시스템의 크기를 조정하는 것보다 훨씬 더 많은 시간이 소요됩니다.
--progress 또는 --verbose 매개변수를 사용하여 더 많은 출력을 볼 수 있는지 궁금합니다.
root@Tiburon3:/tiburon_backup# df -hP .
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/bck_vg-lv_tib_bck 6.8T 12G 6.8T 1% /tiburon_backup
umount /tiburon_backup
root@Tiburon3:/# pvscan
PV /dev/mapper/luks_sda VG bck_vg lvm2 [<232.87 GiB / <232.87 GiB free]
PV /dev/mapper/luks_sdb VG bck_vg lvm2 [<931.50 GiB / <931.50 GiB free]
PV /dev/mapper/luks_sdc VG bck_vg lvm2 [<1.82 TiB / 0 free]
PV /dev/mapper/luks_sdd VG bck_vg lvm2 [149.03 GiB / 149.03 GiB free]
PV /dev/mapper/luks_sde VG bck_vg lvm2 [<1.82 TiB / 0 free]
PV /dev/mapper/luks_sdf VG bck_vg lvm2 [<1.82 TiB / 469.00 GiB free]
PV /dev/mapper/luks_sdg VG bck_vg lvm2 [<931.50 GiB / <931.50 GiB free]
PV /dev/mapper/luks_sdh VG bck_vg lvm2 [149.03 GiB / 149.03 GiB free] #Lets remove this one, for testing purposes, smallest size
PV /dev/mapper/sdb5_crypt VG Tiburon3-vg lvm2 [<148.53 GiB / <111.28 GiB free]
Total: 9 [7.94 TiB] / in use: 9 [7.94 TiB] / in no VG: 0 [0 ]
root@Tiburon3:/# pvdisplay /dev/mapper/luks_sdh
--- Physical volume ---
PV Name /dev/mapper/luks_sdh
VG Name bck_vg
PV Size 149.03 GiB / not usable <3.84 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 38152
Free PE 20437
Allocated PE 17715 **#allright!, this is the scenario I wanted to test. Data migration before removing the disk.**
PV UUID VRhdHD-5aam-9Wha-Qzwg-f8Iz-hosM-Wz0Q3q
root@Tiburon3:/# pvmove /dev/mapper/luks_sdh
No extents available for allocation.
#안전을 위해 LV를 전체 1TB로 줄이는 것이 아니라 800GB로 luks_sdh에서 나머지 할당 PE를 이동하는 데 충분합니다...
root@Tiburon3:/# lvreduce -L -800G /dev/mapper/bck_vg-lv_tib_bck
WARNING: Reducing active logical volume to <6.94 TiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce bck_vg/lv_tib_bck? [y/n]: y
Size of logical volume bck_vg/lv_tib_bck changed from <7.72 TiB (2023191 extents) to <6.94 TiB (1818391 extents).
Logical volume bck_vg/lv_tib_bck successfully resized.
root@Tiburon3:/# pvmove /dev/mapper/luks_sdh --alloc anywhere
/dev/mapper/luks_sdh: Moved: 0.06%
[...]
/dev/mapper/luks_sdh: Moved: 82.00%
[...]
/dev/mapper/luks_sdh: Moved: 99.99%
Done!
root@Tiburon3:/# pvdisplay /dev/mapper/luks_sdh
--- Physical volume ---
PV Name /dev/mapper/luks_sdh
VG Name bck_vg
PV Size 149.03 GiB / not usable <3.84 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 38152
Free PE 38152
Allocated PE 0 **#DATA WAS MOVED OUT OF THIS PV!**
PV UUID VRhdHD-5aam-9Wha-Qzwg-f8Iz-hosM-Wz0Q3q
root@Tiburon3:/# vgreduce bck_vg /dev/mapper/luks_sdh
Removed "/dev/mapper/luks_sdh" from volume group "bck_vg"
root@Tiburon3:/# mount -a
root@Tiburon3:/# cd /tiburon_backup/
root@Tiburon3:/tiburon_backup# du -sh *
10G gentoo_root000.img **#DATA IS INTACT**
지금:
cryptsetup 닫기 luks_sdh
이제 telcoM이 위에서 제안한 대로 /etc/crypttab에서 luks_sdh를 제거(또는 주석 처리)하고 initramfs를 업데이트하는 것이 현명합니다.
initramfs -uv 업데이트
그리고재시작예상대로 작동하는지 테스트합니다.
이제 Private Prod Env에서 실행하겠습니다. ;)
@telcoM님, 조언해주셔서 정말 감사드립니다!