이전에는 시스템의 장치 수준에서의 장애 대응 실습을 진행해봤다. 다른 디스크와 파일 시스템들이 살아있는 한, 나머지가 손상되어도 복구할 수 있었지만, 이번엔 하나의 장치인 서버 컴퓨터 시스템 자체에 문제가 생긴다면? 이는 실제 물리적인 장치의 한계로 인해 전부 재기불능이 될 수가 있다. 따라서 이번엔 같은 네트워크 상의 다른 노드(VM)를 저장소 노드로 만든 후 여기 minio를 깔고 시스템 복구 시도를 해보겠다.
[root@storage ~]# wget https://dl.min.io/server/minio/release/linux-amd64/minio; chmod +x minio; mv minio /usr/local/bin
[root@storage ~]# vi /etc/environment
MINIO_ROOT_USER=backup
MINIO_ROOT_PASSWORD=backup1234
[root@storage ~]# mkdir -p /mnt/data
[root@storage ~]# minio server /mnt/data/ --console-address ":9001" &
[1] 4806
[root@storage ~]# INFO: Formatting 1st pool, 1 set(s), 1 drives per set.
INFO: WARNING: Host local has more than 0 drives of set. A host failure will result in data becoming unavailable.
MinIO Object Storage Server
Copyright: 2015-2025 MinIO, Inc.
License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html
Version: RELEASE.2025-09-07T16-13-09Z (go1.24.6 linux/amd64)
API: http://172.23.195.8:9000 http://127.0.0.1:9000
RootUser: backup
RootPass: backup1234
WebUI: http://172.23.195.8:9001 http://127.0.0.1:9001
RootUser: backup
RootPass: backup1234
CLI: https://docs.min.io/community/minio-object-store/reference/minio-mc.html#quickstart
$ mc alias set 'myminio' 'http://172.23.195.8:9000' 'backup' 'backup1234'
Docs: https://docs.min.io
firewall-cmd --add-port 9000/tcp
success
[root@storage ~]# firewall-cmd --add-port 9001/tcp
success똑같이 서버를 열어준다. 차이점은 이전 디스크 복원 시는 자기 자신의 주소를 사용하고 이번엔 네트워크 상 스토리지 주소로 사용하는 차이가 있다. 이제 다시 메인 실습 노드로 간다.
[root@Alma ~]# mc alias set internal-storage http://172.23.195.8:9000 backup backup1234
[root@Alma ~]# mc mb internal-storage/backup-data
Bucket created successfully `internal-storage/backup-data`.
[root@Alma ~]# mc ls internal-storage
[2025-11-01 15:00:49 KST] 0B backup-data/
미니오 클라이언트 CLI로 내부망 백업 저장소 서버를 추가하고 버킷을 생성한다. restic로 마찬가지로 다시 초기화해줘야 하는데, 기존 로컬 minio의 연결ㅇ르 끊고 내부망 저장소로 연결시켜줘야 한다.
[root@Alma ~]# vi /etc/environment
MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=admin1234
# local minio
#RESTIC_REPOSITORY="s3:http://localhost:9000/raid-data"
#AWS_ACCESS_KEY_ID=$MINIO_ROOT_USER
#AWS_SECRET_ACCESS_KEY=$MINIO_ROOT_PASSWORD
# storage minio (internal network)
RESTIC_REPOSITORY="s3:http://172.23.195.8:9000/backup-data"
AWS_ACCESS_KEY_ID=backup
AWS_SECRET_ACCESS_KEY=backup1234
[root@Alma ~]# source /etc/environment
[root@Alma ~]# restic init
enter password for new repository:
enter password again:
created restic repository cdb5e55e78 at s3:http://172.23.195.8:9000/backup-data
Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.
t[root@Alma ~]# restic backup / --exclude /dev --exclude /proc --exclude /sys --exclude /tmp --exclude /mnt --exclude /media --exclude /lost+found --exclude /run --tag system
enter password for repository:
repository cdb5e55e opened (version 2, compression level auto)
no parent snapshot found, will read all files
[0:00] 0 index files loaded
Files: 30883 new, 0 changed, 0 unmodified
Dirs: 6204 new, 0 changed, 0 unmodified
Added to the repository: 1.395 GiB (837.451 MiB stored)
processed 30883 files, 1.519 GiB in 0:10
snapshot 79e19afb saved
[root@Alma ~]# restic snapshots
enter password for repository:
repository cdb5e55e opened (version 2, compression level auto)
ID Time Host Tags Paths Size
-----------------------------------------------------------------------
79e19afb 2025-11-01 15:18:53 Alma system / 1.519 GiB
-----------------------------------------------------------------------
1 snapshots
[root@Alma ~]# mc ls internal-storage/backup-data
[2025-11-01 15:05:46 KST] 155B STANDARD config
[2025-11-01 15:11:44 KST] 0B data/
[2025-11-01 15:11:44 KST] 0B index/
[2025-11-01 15:11:44 KST] 0B keys/
[2025-11-01 15:11:44 KST] 0B snapshots/이번엔 시스템 전체를 백업시키기 때문에 대상 경로는 최상위인 /로 해준다. 리눅스에선 기본적으로 백업 대상에 포함되지 않는 디렉터리들이 있기에 그 디렉터리들을 제외하고 백업을 설정했다. 시스템 백업이라 크기가 GiB 단위로 큰 것을 알 수 있다. 시스템 고장을 연출하기 위해 중요한 설정 파일들이 있는 /etc를 날려보겠다.
[root@Alma ~]# rm -rf /etc
[root@Alma ~]# ls /
afs bin boot dev home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
[root@Alma ~]# ssh-keygen -t ed25519
No user exists for uid 0설정파일이 싹 다 날라가니 대부분의 명령어들이 구성 파일을 읽지 못해 동작이 안 된다. 내부망의 시스템 백업본을 이용해 시스템 설정 파일을 복구해본다. 여기선 /etc만 날라갔으니 그부분만 가져와서 복원을 시키면 된다.
[root@Alma ~]# restic restore 79e19afb --include /etc --target /
enter password for repository:
repository cdb5e55e opened (version 2, compression level auto)
[0:00] 100.00% 1 / 1 index files loaded
restoring snapshot 79e19afb of [/] at 2025-11-01 15:18:53.899148499 +0900 +0900 by root@Alma to /
Summary: Restored 1456 files/dirs (19.670 MiB) in 0:00
[root@Alma ~]# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519):
Enter passphrase for "/root/.ssh/id_ed25519" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Sn8UX8Ca4DtYzGRhRMbl8cS1+iR7y6lqLQt4t6K+OcY root@Alma
The key's randomart image is:
+--[ED25519 256]--+
| +*oooo.. |
| o=. +o. . |
| * .oo. o |
| = oo o |
| .oS.. + . |
| ..+o. = |
| .o +.o.. o |
| Eo.+o..o o |
| o=+ o++..+ |
+----[SHA256]-----+다시 원래대로 살아나서 명령어도 잘 동작하는 걸 확인이 가능하다. 그러면 이렇게 깔끔하게 오류가 나지 않고 시스템 전체가 맛이 가거나 고장이 나버린다면 어떻게 될까? 한 번 그것도 해보겠다. 커널 파일을 의도적으로 손상시켜 재부팅이 안 되는 상황이다.
[root@Alma ~]# rm -rf /boot
[root@Alma ~]# reboot
예상대로 이젠 아예 시스템에 접근 조차 할 수 없게 됐다. restic으로 복구는 당연히 불가, 로컬에 있는 minio도 묻힌 상태, 그렇기 때문에 내부망에 다른 노드에 백업 저장소 노드를 둔 것. 이건 스냅샷을 가지고 살아있다. Hyper-V 관리자의 DVD드라이브에 다시 동일한 Alma 10 ISO를 집어넣고 실행시켜 복구 모드로 진입한다. Troubleshooting -> Rescue 로 진입하면 됨.
이제 복구 셸 환경에서 다시 restic을 깔고 진행해야 한다. 여기선 dnf가 먹히지 않으므로 직접 가져와서 다운받아야 한다.
bash-5.2# wget -O /tmp/restic.bz2 https://github.com/restic/restic/releases/download/v0.18.1/restic_0.18.1_linux_amd64.bz2
bash-5.2# cd /tmp
bash-5.2# bzip2 -d restic.bz2
bash-5.2# chmod +x /restic
bash-5.2# export AWS_ACCESS_KEY_ID="backup"
bash-5.2# export AWS_SECRET_ACCESS_KEY="backup1234"
bash-5.2# export RESTIC_REPOSITORY="s3:http://172.23.195.8:9000/backup-data"
bash-5.2# restic init그리고 이전과 같이 다시 연결해주자.
그러고 확인하니 잘 됐다. 이제 마지막으로 시스템 전반을 복구시켜서 성공하면 된다.
여기서 이제 백업하기 위해 대상을 확인한다 sda의 파티션들을 복원하면 시스템이 복원된다.
[bash-5.2]# mkdir -p /mnt/target
[bash-5.2]# restic restore 79e19afb --target /mnt/target
그러면 이렇게 뭐가 많이뜨게 된다. 이후, 이전에 마운트했던 모든 파티션과 바인딩을 다시 마운트하고, chroot /mnt/target으로 안으로 진입한 뒤 부트로더 복구를 시도했으나 실패, restic은 파일 시스템의 데이터만을 복구하는 것을 확인할 수 있었다. 따라서 다른 방법으로 시스템을 복구시켜야 한다. 죽은 데이터들은 어쩔 수 없으니 다시 os 재설치를 시작한다.
다시 초기 설치 시 디스크를 싹 비운 후 깨끗한 상태에서 재설치를 한다. 그리고 백업용 이미지로 쓸 clonezilla를 다운받는다.
https://www.clonezilla.org/downloads.php 클론질라는 BMR 백업 시 사용된다고 한다.
storage 노드에도 클론질라를 통한 백업을 하기 위해 nfs 서버를 열어야 한다. 공유폴더를 하나 생성해주고, /etc/exports에 공유 설정을 추가해준다. 설정이 다 되면 시스템대몬을 활성화하고 방화벽을 허용하면 준비가 끝난다.
[root@storage ~]# dnf install -y nfs-utils
[root@storage ~]# mkdir /nfs
[root@storage ~]# chmod -R 777 /nfs/
[root@storage ~]# ip route
default via 172.23.192.1 dev eth0 proto dhcp src 172.23.195.8 metric 100
172.23.192.0/20 dev eth0 proto kernel scope link src 172.23.195.8 metric 100
[root@storage ~]# vi /etc/exports
/nfs 172.23.192.0/20(rw,sync,no_root_squash)
[root@storage ~]# exportfs -ra
[root@storage ~]# systemctl enable --now nfs-server
[root@Storage ~]# firewall-cmd --permanent --add-service=nfs
[root@Storage ~]# firewall-cmd --reload/etc/exports는 nfs를 통해 공유될 디렉터리와 해당 네트워크의 대역, 파일들의 권한 등이 적혀있다. 이후 exportfs -ra로 설정을 바로 적용하고 서버를 연다. 방화벽이 차단하고 있으면 역시 접근이 안 되기에 nfs에 대해서 열어준다.
다운받고 alma리눅스 기본 설치가 완료됐으면 vm을 종료하고 dvd드라이브에 클론질라를 끼워넣는다.
이후, 펌웨어 탭에서 dvd 우선 부팅을 하도록 설정 후 실행하면 된다.
그러면 클론질라가 나오는데 쭉 진행하다가 device-image를 선택하면 된다.
선택 후에는 nfs 서버를 설정하고 nfs4로 넘어간다. 이후 dhcp 선택하여 IP 자동으로 할당받은 다음에 nfs서버가 설치된 storage 서버의 IP를 입력하고 공유폴더로 설정한 /nfs를 입력하면 된다. 이후 초보자 모드 -> savedisk를 선택, 이름은 알아서 정한다(문자는 영어 권장). 대상이 될 디스크를 선택하라고 되어 있는데, 디스크가 여럿이면 다 선택하면 된다. 이후 옵션들은 필수는 아니지만 체크하고 싶으면 하고 화면에 나온 내용들을 보고 적절히 선택하면 된다. 그냥 기본값으로 엔터 엔터 해도 된다. 맨 마지막에는 작업 후 더 할 게 없으면 종료시키면 된다.
[root@storage ~]# ll /nfs/
total 4
drwxr-xr-x. 2 root root 4096 Nov 1 18:33 2025-11-01-18-img모든 백업 작업이 끝났으면 공유폴더에 백업 디스크 이미지가 생긴다. 이제 진짜로 베어메탈 리커버리가 가능해짐.
다시 VM을 껐다가 펌웨어랑 dvd를 빼고 원래 almalinux로 구동시킨 다음 똑같이 시스템 파일을 삭제시켜 본다. 그러면 동일하게 부팅 불가. alma로 접근이 안 된다. 아까 클론질라로 백업본을 떴다면 이번엔 클론질라로 복구를 시킬 차례이다.
동일하게 다시 펌웨어 설정을 변경하고 dvd를 끼고 클론질라로 부팅, 모든 작업은 백업할 때랑 똑같이 진행하다가 savedisk 부분만 restoredisk로 선택하면 된다.
이후 나오는 것들은 적절히 선택하여 진행하면 된다 이미 백업 단계에서 다 해놨기 때문에 복구는 간단하다. 이미 다른 파일들이 파티션에 존재하기 때문에 경고 문구가 뜨는 거니 안심하고 덮어 써도 된다. 디스크 전체(시스템)을 복구하는 거니 시간이 좀 걸릴 수 있다. 모든 작업이 완료되면 vm을 종료하고 다시 기존처럼 부팅하면
모든 시스템 파일이 정상이 된 걸 확인할 수 있다! 이로서 단일 시스템 장애 시 복구를 완료했다.
'리눅스 > 실습' 카테고리의 다른 글
| 리눅스 실습(3) - 파일시스템 실습(백업 마무리) (0) | 2025.11.02 |
|---|---|
| 리눅스 실습(3) - 파일시스템 실습(백업 스케쥴링과 이중화) (0) | 2025.11.01 |
| 리눅스 실습(3) - 파일시스템 실습(결함 허용과 데이터 스냅샷) (0) | 2025.11.01 |
| 리눅스 실습(3) - 파일시스템 실습(RAID 및 파일시스템 복구) (0) | 2025.10.31 |
| 리눅스 실습(3) - 파일시스템 실습(디스크 장치와 파티션) (0) | 2025.10.31 |