■システムバックアップ
※正規OSのシェルにて、
0. 事前調査
parted -l
pvs
vgs
lvs
cat /etc/fstab
blkid
/dev/mapper/rhel-root: UUID="72feb562-c19f-4a7a-a058-0b8741bb8cb5" TYPE="xfs"
/dev/nvme0n1p1: UUID="6CBD-4356" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1b3dce1e-34fe-4e16-be26-ca2a6a9dd554"
/dev/nvme0n1p2: UUID="ee854401-c0bd-43c6-8fce-5326e9f1bbc7" TYPE="xfs" PARTUUID="336a2778-6bf0-44f5-8925-8e91731da6b7"
/opt配下にremiやepel由来のパッケージがインストールされていないか念のため確認
1. 外付けHDD（例: /dev/sda）をマウントして移動
mount /dev/sda /mnt/
cd /mnt
2. ルート上の3つの重要ディレクトリを「1つのtar」にまとめｍる
tar cpf boot_efi.tar --xattrs --acls --one-file-system /boot/efi
tar cpf boot.tar --xattrs --acls --one-file-system /boot
tar cpf sys_core.tar --xattrs --acls /etc /usr /var/lib /var/cache /opt/remi /opt/※epel系
dnf update -y
■システムリストア
※rescue OSのシェルにて、
1. マウントポイントを作成し、内蔵LVM（ルート）と外付けHDDをマウント
vgchange -ay
mkdir -p /mnt/target /mnt/usb
mount /dev/sda /mnt/usb
mount /dev/mapper/rhel-root /mnt/target
2. 内蔵ディスク側のブートパーティションも忘れずにマウントする
mount /dev/nvme0n1p2 /mnt/target/boot
mount /dev/nvme0n1p1 /mnt/target/boot/efi
3. 【超重要】古いデータをピンポイントで削除（100GBの/homeは触らない）
cd /mnt/target
rm -rf etc usr var/lib var/cache opt/remi opt/※epel系
rm -rf boot/*
rm -rf boot/efi/*
4. バックアップから復元（すべて「-C /mnt/target」を指定するのが正解！）
# 展開時に自動的に etc/ や usr/ などの正しいフォルダ位置へ上書き・配置されます
tar xpf /mnt/usb/sys_core.tar --xattrs --acls -C /mnt/target
tar xpf /mnt/usb/boot.tar --xattrs -C /mnt/target/boot --strip-components=1
tar xpf /mnt/usb/boot_efi.tar --xattrs -C /mnt/target/boot/efi --strip-components=2
5. SELinuxのリラベル設定（tar復元時の必須おまじない）
touch /mnt/target/.autorelabel
touch /mnt/target/.autorelabel
6. アンマウントして再起動（gpt方式でなくMBR方式でも可））
cd /
umount /mnt/target/boot/efi
umount /mnt/target/boot
umount /mnt/target
umount /mnt/usb
reboot
- 前ページ
- 次ページ
■システムのサブスクリプション登録
※RedHatアカウントを事前に登録しておく。
Redhat customer portal:https://access.redhat.com/
# subscription-manager register --username <ユーザ名> --password '<パスワード>'
・確認
# subscription-manager identity
システム ID: XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
名前: xymon-server
組織名: XXXXXXXX
組織 ID: XXXXXXXXX
■Red Hat Developer Subscription for Individuals登録
個人ユーザの場合は以下のサイトから登録すると無料でupdateできるようになる。
https://developers.redhat.com/
※RedHatアカウントとはまた別にアカウントを登録する必要がある
上記登録後以下を実行
# subscription-manager refresh
・確認
# subscription-manager list --consumed
使用済みサブスクリプションプールは見つかりませんでした。
⇒Red Hat Developer Subscription for Individuals登録するだけで自動的にすべてのリポジトリが解放され、割り当てが成功していても「使用済み（消費済み）」としてはカウントされず、「見つかりませんでした」と表示されるらしい。
・利用できるリポジトリの一覧表示
# dnf repolist --enabled
サブスクリプション管理リポジトリーを更新しています。
repo id repo の名前
rhel-9-for-x86_64-appstream-rpms Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs)
rhel-9-for-x86_64-baseos-rpms Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)
清書はこれから
■手動でsambaマウント
mount -t cifs -o username=smbuser //192.168.159.128/Share /mnt/smb_share
■fstabに記載
//192.168.159.128/Share /mnt/smb_share cifs credentials=/etc/samba/auth.cred,uid=apache,gid=apache,file_mode=0777,dir_mode=0777,defaults,_netdev 0 0
# mount -a
# systemctl daemon-reload
■mountコマンドを実行すると、デフォルトで以下のmountオプションが適用されている
---中略---
//192.168.159.128/Share on /mnt/smb_share type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=smbuser,uid=48,forceuid,gid=48,forcegid,addr=192.168.159.128,file_mode=0777,dir_mode=0777,soft,nounix,serverino,mapposix,reparse=nfs,nativesocket,symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
■sambaクライアント側で以下を実行
# time cp -p /mnt/smb_share/testfile.img /tmp/
※ちなみにtestfile.imgは5GBのファイルで以下の実行には15秒くらいかかる
■sambaクライアント側でコピー開始から数秒後にsambaサーバ側でネットワークインタフェースを80秒間切断してから再接続
# nmcli device disconnect ens160 ; sleep 80 ; sudo nmcli device connect ens160
■コピー完了後にファイルが壊れてないか確認
# md5sum /mnt/smb_share/testfile.img
ec4bcc8776ea04479b786e063a9ace45 /mnt/smb_share/testfile.img
# md5sum /tmp/testfile.img
ec4bcc8776ea04479b786e063a9ace45 /tmp/testfile.img
■以下のようにretransとecho_intervalを変えてやれば十数秒の瞬断ではsamba接続は120秒おきに5回試行されるようになりコピー時間は伸びるがコピー自体は成功する
//192.168.159.128/Share on /mnt/smb_share type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=smbuser,uid=48,forceuid,gid=48,forcegid,addr=192.168.159.128,file_mode=0777,dir_mode=0777,soft,nounix,serverino,mapposix,reparse=nfs,nativesocket,symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,retrans=5,echo_interval=120,actimeo=1,closetimeo=1)
逆に、,retrans=0,echo_interval=1にしたらコピーが失敗し、ファイルも破損した。
※echo_interval=0はkernelの仕様上許可されない設定範囲らしい
■このほかの考慮点
Webサーバ（バックエンドWebサーバとフロントエンドリバースプロキシ）の両方でTimeout値が存在し、httpd2.4ではデフォルト値は60秒。こちらに抵触してWeb通信がエラーになることがあるらしいが、この場合はWebクライアント側で通信が失敗したことが検知されるはずなので、クライアント側に誤って壊れたコンテンツがダウンロードされることはないらしい。クライアント側がブラウザならエラー画面が表示され、APIクライアントならやはりhttp通信の失敗が検知されるらしい。
ーーーーーーーーーーー以後したがきーーーーーーーーーーーーーーーーーーー
📋 本番作業時の想定挙動リスト（ネットワーク瞬断影響）
1. 前提条件と環境構成
- 作業内容: Web/DBサーバーが経由するネットワーク機器の再起動（想定通信断絶時間: 最大80秒間）
- アクセス領域: ApacheのDocumentRootは、別の共有サーバーからSambaマウント（cifs）されている
- 処理内容: 静的コンテンツ（5GB等）のダウンロード、およびDB（PostgreSQL）に対するユーザー認証（SELECT文のみの参照処理）
- クライアント要件: コンテンツ破損は絶対に不可（NG）。ただし、エラー検知後のクライアント側でのリトライ（再試行）は許容とする。
2. 各レイヤーにおける想定挙動とタイムアウト値
📂 ① ストレージ層（Sambaマウント / CIFS）
- 適用オプション:
retrans=1, echo_interval=60（デフォルト値、または明示的指定） - 想定挙動:
- 機器の切断が発生しても、OSの低レイヤー（TCP Retransmission）が自動的にパケット再送を繰り返し、最大数分間（約15分）バックグラウンドで粘り続けます。
- 80秒の切断であれば、Sambaマウントは「Host is down」等の致命的エラー（マウント解除）にはならず、セッションを完全に維持（暗黙の再マウント）します。
- データ整合性:
cache=strictの働きにより、ファイルが「虫食い（破損）」の状態で読み込まれることは絶対にありません。
🌐 ② Webサーバー層（Apache httpd 2.4 / nginx）
- 適用設定: Apache
Timeout 120/ nginxproxy_read_timeout 120s（★60秒から変更済） - 想定挙動:
- Sambaマウント層がバックグラウンドで粘っている間、Web層へデータが届かなくなるため、Apacheとnginxのタイムアウトタイマーが一斉にカウントを開始します。
- タイムアウト値を 120秒 に拡張しているため、80秒の瞬断中もWebサーバー側が先に諦めてセッションをブチ切ることはありません。 機器が復帰（80秒後）した瞬間に、データ転送が何事もなかったかのように再開されます。
- ※もしデフォルト（60秒）のままだった場合は、80秒を待てずにWebサーバーが接続を切り、クライアントへエラーを返します（これも仕様上検知可能なので許容内です）。
🗄️ ③ データベース層（PostgreSQL）
- 対象処理: ユーザー認証用の
SELECT文（参照のみ） - 想定挙動:
- Sambaと同様にTCPプロトコル上で動いているため、数十秒〜80秒の瞬断であればOSのTCP再送が自動で耐え、復帰後に正常にクエリ結果が返ります。
- データ整合性: データの書き換え（INSERT/UPDATE）を行わないため、DB内のユーザーアカウント情報が破損・消失するリスクは「ゼロ」です。
- ※アプリやDB側で
statement_timeoutが短く（30秒など）設定されている場合、瞬断中にログインを試みた一部のユーザーが「認証タイムアウト（500/504等）」になりますが、データは守られます。
💻 ④ クライアント層（Webブラウザ / APIクライアント）
- 想定挙動:
- ブラウザ（Chrome/Edge等）: HTTPヘッダーの
Content-Lengthを厳密にチェックしています。万が一サーバー側のタイムアウト（60秒など）が先に発動して途中で通信が切れた場合、一時ファイルを隔離して画面に「失敗 - ネットワークエラー」と赤字で明確に表示します。壊れたファイルを正常として保存する盲点は一切ありません。 - APIクライアント: データの不足、あるいはTCPソケットの突然の切断をプログラム上の「例外（Exception）」として100%確実に検知します。
- リトライ実行時: クライアントがエラーを検知してリトライをかければ、復帰後は確実に100%正しいファイルを最初から（または続きから）取得し直すことができます。
- ブラウザ（Chrome/Edge等）: HTTPヘッダーの