ec2とかgce使ってると、スナップショットでほぼ足りる。
最近、物理サーバのバックアップとリストアのリクエストをもらっててRDXも使うことになった。
RDXってのはバックアップ用のメディアで、昔に使ったLTOみたいなもん。
カタログではusb3で180MB/sの転送速度ってあるけど、どうなんやろ。
linuxは自分環境ではubuntuしか使わんけど、そもそも最近のredhatは何が変わったんやろ。
紹介してくれてる方がおられる。作者さんありがとう。
ファイルシステムのバックアップとリストアはdump/restoreじゃなくてxfsdump/xfsrestore使うんやね。
ext4とか使わず、xfsでOSの用意せなアカンな。
物理サーバでRDX使う前の練習として、vmwareでalmalinux9.3使ってフルバックアップとフルリストアやってみる。
vmwareの中で遊ぶ。
だいたいの方向性
rhel9でシステムバックアップするときの参考。
rear(relax and recovery)を使うってあるけど、usb起動がちょっと好かんなぁ。
RDX使ってるこっちを見せてもらうと、シンプルかなと。xfsdump使うんやね。
作者さん紹介してくれてありがとう。
パーティションとlvmを自分で操作して戻すの久しぶり。
ただしrhel9使うんやけど、できるんかな？
linuxを準備
普通にインストールしてく。
20GBぐらいあれば足りるかな。
メディアとvmの用意しましょ。
isoのダウンロード
どこでもええんやけど、自分はこのへんでダウンロードした。
http://ftp.riken.jp/Linux/almalinux/9.3/isos/x86_64/
vmの準備
rhel9としてalmalinux9を動かしてく。
cpuコア数とかメモリとか適当に入れといて、不要なデバイスも外してisoイメージを使うように設定しとく。
isoイメージから起動して１行目のインストールを選んで進めてく。
「ソフトウェアの選択」GUIつきのサーバを選んどく。
kdumpはいらんから、rootユーザのパスワードつけて一般ユーザを１つ作るようにする。
ファイルシステムにxfs使いたいから、パーティション作成は自動じゃなくて、手動で指定する。バックアップのテストやからswapって要らんけど、まぁつけとくか。
必要な指定が終わったら「インストールの開始」のボタンが選べる。
１０分ぐらいでインストール終わるからOS再起動してログイン画面になってくれるのを待つ。
普通にGUIログインできたら、いったんOS停止してバックアップ用のパーティションの用意する。
20GBのパーティションやけど同じサイズにしたら見分けつかんから、30GBのパーティション作る。
OS起動したらユーティリティの中にディスク操作できるツールがあるから開いてみる。
昔はこんなのなくてコマンドラインでチマチマやってた。
どっちかっていうとキライな作業。
今はmacのディスクユーティリティに似せたのが使えて助かる。
パーティションが見えてて、起動時の接続設定とかマウントポイント指定とか視覚的にできる。
画面上はなぜか32GBディスクって書いてるけど、これ選んで右クリックして使い始める。
即できる。ああ楽チン。
コマンドラインで/backupのマウントポイント作ってからさらに設定してく。
昔にfstabに書いたオプションとか、よしなに入ってくれるっぽい。
バックアップ置き場用としてのパーティション(/dev/nvme0n2)をxfsで30GB用意して、/backupで使えるようになった。
[nari@alma9 ~]$ df -hT
ファイルシス タイプ サイズ 使用 残り 使用% マウント位置
devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs tmpfs 775M 9.6M 765M 2% /run
/dev/mapper/almalinux-root xfs 17G 5.5G 12G 32% /
/dev/nvme0n1p1 xfs 960M 269M 692M 28% /boot
/dev/nvme0n2 ext4 30G 3.2G 25G 12% /backup
tmpfs tmpfs 388M 124K 388M 1% /run/user/1000
[nari@alma9 ~]$ fdiskの状態確認
今までは/dev/sdナントカってパーティションやったのが、/dev/nvmeナントカってのになってる。
やってみてわかったけど、OS起動してるときにはディスク追加できない。
nvme0n1p1は/bootのことで起動のトグル「*」がついてる。
[root@alma9 ~]# fdisk -l
ディスク /dev/nvme0n1: 20 GiB, 21474836480 バイト, 41943040 セクタ
ディスク型式: VMware Virtual NVMe Disk
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0xd1705d10
デバイス 起動 開始位置 終了位置 セクタ サイズ Id タイプ
/dev/nvme0n1p1 * 2048 2099199 2097152 1G 83 Linux
/dev/nvme0n1p2 2099200 41943039 39843840 19G 8e Linux LVM
ディスク /dev/nvme0n2: 30 GiB, 32212254720 バイト, 62914560 セクタ
ディスク型式: VMware Virtual NVMe Disk
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスク /dev/mapper/almalinux-root: 17 GiB, 18249416704 バイト, 35643392 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスク /dev/mapper/almalinux-swap: 2 GiB, 2147483648 バイト, 4194304 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイトblkidの状態も確認
[root@alma9 ~]# blkid
/dev/mapper/almalinux-swap: UUID="b74fabbd-ead2-4049-833a-f8741fb1dd2b" TYPE="swap"
/dev/nvme0n1p1: UUID="426c3e3f-e4da-4dbd-9c2d-904d7c4f96f3" TYPE="xfs" PARTUUID="d1705d10-01"
/dev/nvme0n1p2: UUID="Nvdo7O-f0Gk-rXBg-SMzt-OmhC-e4Od-n2sJlF" TYPE="LVM2_member" PARTUUID="d1705d10-02"
/dev/nvme0n2: LABEL="backup" UUID="7e5a49c2-74fd-4e03-bd2b-c18c784258b4" TYPE="ext4"
/dev/mapper/almalinux-root: UUID="034dcdfb-4d58-4847-9210-bb9a4efd92cf" TYPE="xfs"
[root@alma9 ~]#dnfで最新にしとく
初回は長いログやし省略。
[root@alma9 ~]# dnf update
:(中略)
完了しました!
[root@alma9 ~]# selinux無効にしとく
この機能ウザいから切る。
有効にして使うと扱いにくくなるからオフ。
[root@alma9 ~]# cat /etc/sysconfig/selinux | grep SELINUX=
# SELINUX= can take one of these three values:
# NOTE: Up to RHEL 8 release included, SELINUX=disabled would also
##SELINUX=enforcing
SELINUX=disabled
[root@alma9 ~]# getenforce
Disabled
[root@alma9 ~]# xfsdump入れとく
ログ取るの忘れた・・・。
ま、ええか。
[root@alma9 ~]# dnf install xfsdump
AlmaLinux 9 - AppStream 6.3 kB/s | 4.1 kB 00:00
AlmaLinux 9 - BaseOS 6.0 kB/s | 3.8 kB 00:00
AlmaLinux 9 - Extras 5.9 kB/s | 3.8 kB 00:00
パッケージ xfsdump-3.1.12-3.el9.x86_64 は既にインストールされています。
依存関係が解決しました。
行うべきことはありません。
完了しました!
[root@alma9 ~]# ファイル確認に使うgit入れとく
touchしてもええんやけど、gitで何かとってきて置いてみるのに使う。
[root@alma9 ~]# dnf install git
メタデータの期限切れの最終確認: 0:09:36 前の 2023年12月04日 07時06分46秒 に実施しました
:(中略)
インストール済み:
git-2.39.3-1.el9_2.x86_64 git-core-2.39.3-1.el9_2.x86_64
git-core-doc-2.39.3-1.el9_2.noarch perl-Error-1:0.17029-7.el9.noarch
perl-Git-2.39.3-1.el9_2.noarch perl-TermReadKey-2.38-11.el9.x86_64
perl-lib-0.65-480.el9.x86_64
完了しました!
[root@alma9 ~]#何かファイル置いとく
gitで何かクローンしとこ。
あとでdiffとかやってみるか。
ここではwinmergeのソースをとってきてる。
github見たらたまたま見つけた。
バックアップ領域にコピーしておいて、作業前はdiffで差分なし。
[nari@alma9 ~]$ git clone https://github.com/WinMerge/winmerge.git
Cloning into 'winmerge'...
remote: Enumerating objects: 147717, done.
remote: Counting objects: 100% (1933/1933), done.
remote: Compressing objects: 100% (166/166), done.
remote: Total 147717 (delta 1833), reused 1800 (delta 1767), pack-reused 145784
Receiving objects: 100% (147717/147717), 470.07 MiB | 22.15 MiB/s, done.
Resolving deltas: 100% (71901/71901), done.
[nari@alma9 ~]$ su -
パスワード:
[root@alma9 ~]# cp -pR /home/nari/winmerge /backup/
[root@alma9 ~]# diff -r /home/nari/winmerge /backup/winmerge
[root@alma9 ~]# サービスの状態確認
これもフルリストア後に同じになるはず。
[root@alma9 ~]# systemctl list-unit-files -t service | grep enabled > /backup/systemctlList.txt
[root@alma9 ~]# cat /backup/systemctlList.txt
accounts-daemon.service enabled enabled
atd.service enabled enabled
auditd.service enabled enabled
avahi-daemon.service enabled enabled
bluetooth.service enabled enabled
chronyd.service enabled enabled
crond.service enabled enabled
cups.service enabled enabled
dbus-broker.service enabled enabled
firewalld.service enabled enabled
gdm.service enabled enabled
getty@.service enabled enabled
irqbalance.service enabled enabled
iscsi-onboot.service enabled enabled
iscsi.service enabled enabled
kdump.service enabled enabled
libstoragemgmt.service enabled enabled
low-memory-monitor.service enabled enabled
lvm2-monitor.service enabled enabled
mcelog.service enabled enabled
mdmonitor.service enabled enabled
microcode.service enabled enabled
ModemManager.service enabled enabled
multipathd.service enabled enabled
NetworkManager-dispatcher.service enabled enabled
NetworkManager-wait-online.service enabled disabled
NetworkManager.service enabled enabled
nis-domainname.service enabled enabled
nvmefc-boot-connections.service enabled enabled
ostree-remount.service enabled enabled
power-profiles-daemon.service enabled enabled
qemu-guest-agent.service enabled enabled
rsyslog.service enabled enabled
rtkit-daemon.service enabled enabled
selinux-autorelabel-mark.service enabled enabled
smartd.service enabled enabled
spice-vdagentd.service indirect enabled
sshd.service enabled enabled
sssd.service enabled enabled
switcheroo-control.service enabled enabled
systemd-boot-update.service enabled enabled
systemd-network-generator.service enabled enabled
systemd-pstore.service disabled enabled
systemd-remount-fs.service enabled-runtime disabled
tuned.service enabled enabled
udisks2.service enabled enabled
upower.service enabled enabled
vgauthd.service enabled disabled
vmtoolsd.service enabled enabled
[root@alma9 ~]# LVMのための構成情報をバックアップ
lvmはlogical volume managerのこと。
複数のディスクをまとめて管理してくれる仕組みで、500GBx3のディスクをまとめて１つのボリュームに見せてくれたりする。
初めて使ったのはaixのlvmやったかな。
awsのec2とか使うと、lvm使ってる感覚がほとんどないから忘れてる。
pvdisplay/vgdisplay/lvdisplayとかして確認する。
ここではvgcfgbackupで設定逃がしておいて、リストアのときに使う。
uuidで小文字の「L」が数字の１に見えてうとっとおしい・・・。
参考ページにはなかったけど、vgcfgbackupの出力結果ってこんなんなってるんやなぁ。
[root@alma9 ~]# vgcfgbackup -f /backup/vgcfgbackup.txt
Volume group "almalinux" successfully backed up.
[root@alma9 ~]# cat /backup/_vgcfgbackup.txt
# Generated by LVM2 version 2.03.21(2) (2023-04-21): Mon Dec 4 07:25:02 2023
contents = "Text Format Volume Group"
version = 1
description = "vgcfgbackup -f /backup/vgcfgbackup.txt"
creation_host = "alma9" # Linux alma9 5.14.0-362.8.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Nov 7 14:54:22 EST 2023 x86_64
creation_time = 1701642302 # Mon Dec 4 07:25:02 2023
almalinux {
id = "JKFHMx-vr3Z-Zkw3-G9QV-QEyH-flDC-RvJOAZ"
seqno = 3
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "Nvdo7O-f0Gk-rXBg-SMzt-OmhC-e4Od-n2sJlF"
device = "/dev/nvme0n1p2" # Hint only
device_id_type = "sys_wwid"
device_id = "eui.14ec730fcc9864d4000c296f130b6e61"
status = ["ALLOCATABLE"]
flags = []
dev_size = 39843840 # 18.999 Gigabytes
pe_start = 2048
pe_count = 4863 # 18.9961 Gigabytes
}
}
logical_volumes {
root {
id = "IUytHi-nuYk-ABgT-bVGb-10jK-8oxc-1VdoMZ"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_time = 1701374514 # 2023-12-01 05:01:54 +0900
creation_host = "alma9"
segment_count = 1
segment1 {
start_extent = 0
extent_count = 4351 # 16.9961 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
swap {
id = "mlhaDZ-Bgau-dEbo-r1YK-jCe9-X9sI-MmFSMl"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_time = 1701374514 # 2023-12-01 05:01:54 +0900
creation_host = "alma9"
segment_count = 1
segment1 {
start_extent = 0
extent_count = 512 # 2 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 4351
]
}
}
}
}
[root@alma9 ~]# blkidの情報もバックアップしとく。
[root@alma9 ~]# blkid > /backup/blkid.txt
[root@alma9 ~]# cat /backup/blkid.txt
/dev/mapper/almalinux-swap: UUID="b74fabbd-ead2-4049-833a-f8741fb1dd2b" TYPE="swap"
/dev/nvme0n1p1: UUID="426c3e3f-e4da-4dbd-9c2d-904d7c4f96f3" TYPE="xfs" PARTUUID="d1705d10-01"
/dev/nvme0n1p2: UUID="Nvdo7O-f0Gk-rXBg-SMzt-OmhC-e4Od-n2sJlF" TYPE="LVM2_member" PARTUUID="d1705d10-02"
/dev/nvme0n2: LABEL="backup" UUID="7e5a49c2-74fd-4e03-bd2b-c18c784258b4" TYPE="ext4"
/dev/mapper/almalinux-root: UUID="034dcdfb-4d58-4847-9210-bb9a4efd92cf" TYPE="xfs"
[root@alma9 ~]# フルバックアップ
対象はこのあたり。
1GBと19GBちゃんとバックアップとれるかな。
デバイス 起動 開始位置 終了位置 セクタ サイズ Id タイプ
/dev/nvme0n1p1 * 2048 2099199 2097152 1G 83 Linux
/dev/nvme0n1p2 2099200 41943039 39843840 19G 8e Linux LVM見た目が似てるけど、lvmは拡張パーティションとは違う。
lvmっていうファイルシステムの種類を選んでおいて、その中でswapとかルートパーティションを作って使っていく。
バックアップ方法
参考にさせてもらったサイトに書いてあったものを見て、xfsdumpにパーティションを指定。
gzipで「-9」って懐かしい書き方やな。
tarやったかufsdumpやったか、テープアーカイブのとき書いたような気がする。
ターゲットマシンもrtxメディア使わせてもらうから、参考ページほぼそのまま。
# xfsdump -l0 - /dev/nvme0n1p1 | gzip -9 > /backup/boot.gz
# xfsdump -l0 - /dev/mapper/almalinux-root | gzip -9 > /backup/root.gzデータもOS設定もバックアップ
１つ目の実行結果。１分以内で終わった。1GB未満で小さいし。
[root@alma9 ~]# xfsdump -l0 - /dev/nvme0n1p1 | gzip -9 > /backup/boot.gz
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.1.12 (dump format 3.0)
xfsdump: level 0 dump of alma9:/boot
xfsdump: dump date: Mon Dec 4 13:45:20 2023
xfsdump: session id: 83602e94-ac77-41a9-a530-13ccf3e162d7
xfsdump: session label: ""
xfsdump: ino map phase 1: constructing initial dump list
xfsdump: ino map phase 2: skipping (no pruning necessary)
xfsdump: ino map phase 3: skipping (only one dump stream)
xfsdump: ino map construction complete
xfsdump: estimated dump size: 240384960 bytes
xfsdump: creating dump session media file 0 (media 0, file 0)
xfsdump: dumping ino map
xfsdump: dumping directories
xfsdump: dumping non-directory files
xfsdump: ending media file
xfsdump: media file size 240089920 bytes
xfsdump: dump size (non-dir files) : 239835448 bytes
xfsdump: dump complete: 7 seconds elapsed
xfsdump: Dump Status: SUCCESS
[root@alma9 ~]# ２つ目の実行結果。１０分ぐらいかかった。20GBのうち5GBが実際に使ってる容量やから、１分0.5GBぐらいなんかな。
今はvmdkやけどRDXになったらもっと速度上がるんやろか。
[root@alma9 backup]# xfsdump -l0 - /dev/mapper/almalinux-root | gzip -9 > /backup/root.gz
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.1.12 (dump format 3.0)
xfsdump: level 0 dump of alma9:/
xfsdump: dump date: Tue Dec 5 01:46:27 2023
xfsdump: session id: 68140594-3172-4001-8ef8-b96314e0c3f3
xfsdump: session label: ""
xfsdump: ino map phase 1: constructing initial dump list
xfsdump: ino map phase 2: skipping (no pruning necessary)
xfsdump: ino map phase 3: skipping (only one dump stream)
xfsdump: ino map construction complete
xfsdump: estimated dump size: 5611228160 bytes
xfsdump: creating dump session media file 0 (media 0, file 0)
xfsdump: dumping ino map
xfsdump: dumping directories
xfsdump: dumping non-directory files
xfsdump: ending media file
xfsdump: media file size 5441412576 bytes
xfsdump: dump size (non-dir files) : 5346486360 bytes
xfsdump: dump complete: 407 seconds elapsed
xfsdump: Dump Status: SUCCESS
[root@alma9 backup]# フルリストア
いったん作ったvmのバックアップとる。
ssdで2分も待つとコピーが終わる。
バックアップあるからvmdkファイルの新品を設置して使う。
2GB分割してるから、通し番号のないファイルにvmdk定義が入り、通し番号がついたファイルにデータの実態が入る。
レスキューモードで起動
vmxにbios起動までの時間書く方法もあるけど、めっちゃ連打してF2でbiosの画面開く。
しもた。
phoenix biosのハードコピー忘れた・・・。
vmのbiosで起動順位をハードディスクより先にdvd読むようにしとく。
dvdブートしてコマンドライン使う
インストール用のisoで起動したら「Troubleshooting」が三行目にあるから選んで起動。
次の画面で二行目の「Rescue a Almalinux system」選ぶ。
さらに次の画面で「3)Skip to shell」を選ぶとbashが使える。
バックアップを参照できるようにしとく
さっき取ったバックアップの入ったパーティションをdvd起動のrescueモードでも使えるようにマウントポイントを作る。
レスキューモードのvmは文字のコピペができん・・・。
vmware tools動いてへんからそらそうやわなぁ。
パーティションを初期化
作る予定のパーティションはこんな感じ。
デバイス 起動 開始位置 終了位置 セクタ サイズ Id タイプ
/dev/nvme0n1p1 * 2048 2099199 2097152 1G 83 Linux
/dev/nvme0n1p2 2099200 41943039 39843840 19G 8e Linux LVM実際にfdiskしてくんやけど、だいたいやったことはこんな感じ。
2TBを超えるディスクだとfdiskじゃダメでparted使う。
p -> パーティションの状態表示(print)
n -> パーティションの作成(new)で２つ作る
t -> パーティションのファイルシステムタイプ変更(type)で２つ目のパーティションをlinux lvmにする
w -> パーティション情報を書き込む(write)
q -> fdiskを終了する(quit)ファイルシステムにはlinuxパーティションの83と、linux lvmの8eを使う。実際のコマンドラインはこんな感じ。
[root@alma9 ~]# fdisk /dev/nvme0n1
fdisk (util-linux 2.37.4) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。
書き込みコマンドを使用する際は、注意して実行してください。
This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.
コマンド (m でヘルプ): n
パーティションタイプ
p 基本パーティション (0 プライマリ, 0 拡張, 4 空き)
e 拡張領域 (論理パーティションが入ります)
選択 (既定値 p): p
パーティション番号 (1-4, 既定値 1):
最初のセクタ (2048-41943039, 既定値 2048):
最終セクタ, +/-セクタ番号 または +/-サイズ{K,M,G,T,P} (2048-41943039, 既定値 41943039): +1G
新しいパーティション 1 をタイプ Linux、サイズ 1 GiB で作成しました。
コマンド (m でヘルプ): p
ディスク /dev/nvme0n1: 20 GiB, 21474836480 バイト, 41943040 セクタ
ディスク型式: VMware Virtual NVMe Disk
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0xd1705d10
デバイス 起動 開始位置 終了位置 セクタ サイズ Id タイプ
/dev/nvme0n1p1 2048 2099199 2097152 1G 83 Linux
パーティション 1 にあるファイルシステム/RAIDの署名が完全に消去されます。
コマンド (m でヘルプ): n
パーティションタイプ
p 基本パーティション (1 プライマリ, 0 拡張, 3 空き)
e 拡張領域 (論理パーティションが入ります)
選択 (既定値 p): p
パーティション番号 (2-4, 既定値 2): 2
最初のセクタ (2099200-41943039, 既定値 2099200):
最終セクタ, +/-セクタ番号 または +/-サイズ{K,M,G,T,P} (2099200-41943039, 既定値 41943039):
新しいパーティション 2 をタイプ Linux、サイズ 19 GiB で作成しました。
コマンド (m でヘルプ): p
ディスク /dev/nvme0n1: 20 GiB, 21474836480 バイト, 41943040 セクタ
ディスク型式: VMware Virtual NVMe Disk
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0xd1705d10
デバイス 起動 開始位置 終了位置 セクタ サイズ Id タイプ
/dev/nvme0n1p1 2048 2099199 2097152 1G 83 Linux
/dev/nvme0n1p2 2099200 41943039 39843840 19G 83 Linux
パーティション 1 にあるファイルシステム/RAIDの署名が完全に消去されます。
コマンド (m でヘルプ): t
パーティション番号 (1,2, 既定値 2): 2
16 進数コード (L で利用可能なコードを一覧表示します): L
0 空 24 NEC DOS 81 Minix / 古い Li bf Solaris
1 FAT12 27 隠し NTFS WinRE 82 Linux スワップ c1 DRDOS/sec (FAT-
2 XENIX root 39 Plan 9 83 Linux c4 DRDOS/sec (FAT-
3 XENIX usr 3c PartitionMagic 84 隠し OS/2 また c6 DRDOS/sec (FAT-
4 FAT16 <32M 40 Venix 80286 85 Linux 拡張領域 c7 Syrinx
5 拡張領域 41 PPC PReP Boot 86 NTFS ボリューム da 非 FS データ
6 FAT16 42 SFS 87 NTFS ボリューム db CP/M / CTOS / .
7 HPFS/NTFS/exFAT 4d QNX4.x 88 Linux プレーン de Dell ユーティリ
8 AIX 4e QNX4.x 第2パー 8e Linux LVM df BootIt
9 AIX 起動可能 4f QNX4.x 第3パー 93 Amoeba e1 DOS access
a OS/2 ブートマネ 50 OnTrack DM 94 Amoeba BBT e3 DOS R/O
b W95 FAT32 51 OnTrack DM6 Aux 9f BSD/OS e4 SpeedStor
c W95 FAT32 (LBA) 52 CP/M a0 IBM Thinkpad ハ ea Rufus alignment
e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a5 FreeBSD eb BeOS fs
f W95 拡張領域 (L 54 OnTrackDM6 a6 OpenBSD ee GPT
10 OPUS 55 EZ-Drive a7 NeXTSTEP ef EFI (FAT-12/16/
11 隠し FAT12 56 Golden Bow a8 Darwin UFS f0 Linux/PA-RISC
12 Compaq 診断 5c Priam Edisk a9 NetBSD f1 SpeedStor
14 隠し FAT16 <32M 61 SpeedStor ab Darwin ブート f4 SpeedStor
16 隠し FAT16 63 GNU HURD または af HFS / HFS+ f2 DOS セカンダリ
17 隠し HPFS/NTFS 64 Novell Netware b7 BSDI fs fb VMware VMFS
18 AST SmartSleep 65 Novell Netware b8 BSDI スワップ fc VMware VMKCORE
1b 隠し W95 FAT32 70 DiskSecure Mult bb 隠し Boot Wizar fd Linux raid 自動
1c 隠し W95 FAT32 75 PC/IX bc Acronis FAT32 L fe LANstep
1e 隠し W95 FAT16 80 古い Minix be Solaris ブート ff BBT
16 進数コード (L で利用可能なコードを一覧表示します): 8e
パーティションのタイプを 'Linux' から 'Linux LVM' に変更しました。
コマンド (m でヘルプ): p
ディスク /dev/nvme0n1: 20 GiB, 21474836480 バイト, 41943040 セクタ
ディスク型式: VMware Virtual NVMe Disk
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0xd1705d10
デバイス 起動 開始位置 終了位置 セクタ サイズ Id タイプ
/dev/nvme0n1p1 2048 2099199 2097152 1G 83 Linux
/dev/nvme0n1p2 2099200 41943039 39843840 19G 8e Linux LVM
パーティション 1 にあるファイルシステム/RAIDの署名が完全に消去されます。
コマンド (m でヘルプ): wdvdブートしたときのレスキューlinuxはvmで文字コピーができんかったから、上記は普通のalmalinuxで一時的に実行して作ったリスト。
だからfdiskは日本語表記。
最初、fdiskしたときに/dev/nvme0n1p1に起動のトグルつけてた。
そしたらgrubでエラーになってOS起動できず・・・。
なんか見落としてるだけかもしれんけど・・・。
２回ぐらいfdiskからやり直して、pvcreateも実行し直した。
このとき、fdiskで起動のトグルはつけないようにし、パーティション作成はセクタ指定じゃなくて「+1G」って入れたら先に進めた。
リストア完了直後のディスク状態はこんな感じ。
ファイルシステムの設定ってけっこう面倒。
今回はlvm作ったけど、複雑な構成やったらインストーラでいったんパーティション作って普通にOSインストールして、レスキューモードにしてからrootパーティションだけxfsrestoreしてもええんとちゃうかと思う。
LVM情報がないことを確認
ディスク初期化したんやから、そらないわな。
これから作る状態やから、xxdisplayの３つのコマンドは１つもコマンドラインが戻ってこないことを確認する。
# pvdisplay
# vgdisplay
# lvdisplayLVMの復旧
uuidの入力めっちゃやりにくかった。
注意するのは、pvcreateするdevのパス、vgcfgrestoreとvgchangeはバックアップしておいた名前の指定。
pvcreate --uuid Nvdo7O-f0Gk-rXBg-SMzt-OmhC-e4Od-n2sJlF --restorefile /backup/vgcfgbackup.txt /dev/nvme0n1p2
vgcfgrestore -f /backup/vgcfgbackup.txt almalinux
vgchange -ay almalinuxやってみたらこうなる。
エラー出てないことと、vgdisplayとか確認してみてる。
ファイルシステムを作成。
これもuuidの入力がツラい。
# mkfs.xfs -f /dev/nvme0n1p1
# xfs_admin -U 426c3e3f-e4da-4dbd-9c2d-904d7c4f96f3 /dev/nvme0n1p1
# mkfs.xfs -f /dev/mapper/almalinux-root
# xfs_admin -U 034dcdfb-4d58-4847-9210-bb9a4efd92cf /dev/mapper/almalinux-root
# mkswap -U b74fabbd-ead2-4049-833a-f8741fb1dd2b /dev/mapper/almalinux-swapわかりにくいけど、/bootパーティション作成。
次はルートパーティションとスワップパーティションの作成。
パーティションにデータをリストアするための一時的なパーティションを作る。
# mkdir /mnt/boot
# mkdir /mnt/root
# mount /dev/nvme0n1p1 /mnt/boot
# mount /dev/mapper/almalinux-root /mnt/rootこんな感じでマウント。
リストア行くで
さぁここまで来たらあと少し。
バックアップと同じぐらいの時間でリストアが終わった。
# zcat /backup/boot.gz | xfsrestore - /mnt/boot
# zcat /backup/root.gz | xfsrestore - /mnt/root１つ目の/bootパーティションのリストア。
２つ目のルートパーティションのリストア。
処理時間101秒ってあるのはだいたいあってるかな。
最終的なパーティション。
起動のトグルつけてない。
デバイス 起動 開始位置 終了位置 セクタ サイズ Id タイプ
/dev/nvme0n1p1 2048 1955839 1953792 954M 83 Linux
/dev/nvme0n1p2 1955840 41943039 39987200 19.1G 8e Linux LVMいったんここまででOS停止させる。
リストア後の確認
dvd起動させないように起動時のデバイス接続を外しておく。
dvdやなくてhddブートさせると起動してログインできた。
/bootバーティション読み込んでgrub2経由でOS起動できてるってことで、ブートシーケンス維持できてる。
GUIでログインできるやん。
suもできてたから、OSユーザの情報とか認証も維持できてるってことやな。
次、OSの状態確認。selinuxオフしたのとdnfでインストールしたxfsdumpとgitが生きてる。
[root@alma9 backup]# getenforce
Disabled
[root@alma9 backup]# which xfsdump
/usr/sbin/xfsdump
[root@alma9 backup]# which git
/usr/bin/gitgitでとってきたデータも維持できてる。差分があらへん。
[root@alma9 backup]# diff -r /home/nari/winmerge /backup/winmerge
[root@alma9 backup]# サービスの起動状態も維持できてる。完全一致やね。
おお、完全リカバリできたんとちゃうか。
[root@alma9 backup]# systemctl list-unit-files -t service | grep enabled > /backup/systemctlList.txt
[root@alma9 backup]# diff _systemctlList.txt systemctlList.txt
[root@alma9 backup]# インストーラで初期化した後のフルリストア
fdiskでパーティション作り直すはけっこう面倒。
かなり昔、まだ仮想化をpcでやってない頃にwindowsとlinuxのデュアルブートとかやってたことがある。
linuxのgrubはその頃からあって、windowsのパーティションを作って入れてから、linuxのパーティションを作り、grubで選んでから起動してたっけ。
その頃からfdiskはあったけど、2010年頃には2TBを超えるパーティションを扱うときはparted使って操作してたかな。
パーティション操作は設定間違うとOS起動してこないから、結構デリケートなんよね。
パーティションをインストーラで作り直す
リストアした後、vmdkを作り直してもう１回インストールした。
パーティションは20GBのディスクにいったん前と同じ構成を作った。
普段作らんけどswapもやっとこ。
rootパーティションだけ戻せばいいかって思ったらそうでもなかったんで、戻せるかどうか試行錯誤してみたら戻せた。
レスキューモードで起動してパーティションいじる
やってみるのはこんな内容。
vgchangeでLVMにあるalamlinuxのルートパーティションが見えるようにしといて、あとは/bootと/rootの元のUUIDで識別できるようにしとく。
# vgchange -ay almalinux
# mkfs.xfs -f /dev/nvme0n1p1
# xfs_admin -U 426c3e3f-e4da-4dbd-9c2d-904d7c4f96f3 /dev/nvme0n1p1
# mkfs.xfs -f /dev/mapper/almalinux-root
# xfs_admin -U 034dcdfb-4d58-4847-9210-bb9a4efd92cf /dev/mapper/almalinux-rootやってみたらこうなる。
xfs_adminでuuidが前の状態になるようにしとかんと、OS起動できん。
OS入れ直したらパーティションのuuid変わってまうから、xfsdumpしたときのuuidを設定したらなアカン。
チマチマとuuid入力した。
次はリストアするためのパーティションを一時的に作ってマウントする。
リストアする
あとはリストアする。
# zcat /backup/boot.gz | xfsrestore - /mnt/boot
# zcat /backup/root.gz | xfsrestore - /mnt/rootリストア終わったら念の為、blkidの内容を確認しとく。
bootとrootのuuidが前と同じを確認したらOS再起動して使えるようになった。
xfsrestoreで使うデータ同じやから、そら戻るわな。
リカバリで一番しんどかったのは、uuidの入力にコピペが使えんかったり、数字の「１」と小文字のエル「ｌ」を読み違えたりしたことかな。
最初はgrub2でエラー出て苦しかったこともあった。
３回目ぐらいのチャレンジでフルリカバリできたんで、よかったよかった。
OSを再インストールしたときもuuidで悩んだけど、vgchangeしてmkfs.xfs/xfs_adminしたらいけた。
vmで練習したから次は実機でやってみよっかね。
たぶんuefiやからちょっと工夫がいるんかな。
実機での顛末(rdx関連)
年末にお客様の実機を預かって実際にやってみた。
実機は2023年のものなのでefiのパーティションが存在するから、そのあたりはalmalinux9(redhat9 clone)でefi利用のxfsフルバックアップとフルリストアでやったこととほぼ同じことした。
ここではrdx利用の顛末。
他の顛末は上の投稿で書いとく。
rdxをフォーマット
用意したスクリプトはコメントヘッダがついてたりログ出力してるから抜粋。
:(中略)
read -p "--- RDX format ready ? ---(y/N)" y
case "$yn" in [yY]*) ;; *) echo "abort." ; exit ;; esac
parted -s -a optimal /dev/sdb -- mklabel gpt
parted -s -a optimal /dev/sdb -- mkpart RDX-part ext3 2024s 100%
sync ; sync
mke2fs -j -T largefile4 /dev/sdb
sync ; sync
exit最初のread〜caseは確認プロンプト。
「y」か「Y」推したら後続処理に進んで、そうじゃなかったら処理終わり。
RDXは2TBのものを注文されてたので、partedでパーティション作って、メーカーのマニュアルにあったmk2fsでのファイルシステム作成。
中身は完全に抹消されてext3としてマウントできる。
redhat9を「GUIサーバ」としてインストールすると、6GB程度ディスク消費する。
xfsdumpでgzファイル作らせて、バックアップにかかる時間は５分程度。
リストアもほぼ同じやった。
gzで圧縮しながらやから厳密には違うかもしれんけど、6GBで５分程度やったら、
300sec=6GB → 3sec=61.44MB で１秒あたり20.48MBぐらい処理してるんかな。
クラウドのサーバばっかりやってるから、rdxドライブの存在知らんかった。
巻き戻しとかしながら書くんかと思ってたら、普通のパソコンのハードディスクより少し遅いぐらいって感じやった。
それにしても1.5k回転のsasのhddはうるさくて耳痛かったなぁ・・・。
