모든 백업 구성이 완료되었다! 네트워크 파일 공유 설정과 스냅샷 백업 스케줄링과 부팅 ISO로 대비, 내부망에 구성한 minio 오브젝트 스토리지와 외부 클라우드 서비스 오브젝트 스토리지인 r2로의 크론을 통한 스케쥴링 동기화로 스냅샷이 생성될 시, nfs를 타고 스토리지에 이중화 저장이 되는 파이프라인을 구축하였다.
이제 진짜 마지막으로 vm을 죽이고 살려보자! veeam이 깔려 있고, nfs로 접근도 해놨기 때문에 이 상태가 다시 유지되어야 한다.
[root@storage ~]# ls /nfs/
2025-11-01-18-img 'Alma veeam-snapshot'
veeam-recovery-amd64-6.0.0.iso veeam-recovery-amd64-6.0.0.iso.1
[root@Alma ~]# rm -rf /etc /nfs /var /boot
[root@storage ~]# ll /nfs/
total 0모든 대비가 끝났기 때문에 두려울 것이 없다. 시원하게 nfs 포함 시스템 파일들을 날린다!
nfs는 네트워크 모두가 같이 바라보기 때문에 당연히 스토리지 노드에서도 지워진 게 확인이 된다.
그러나 이미 다른 곳인 miniO와 R2에 그대로 동기화시켜 저장을 해놨으므로 이걸 가지고 복구를 하면 된다. 재부팅을 시키자
부팅이 실패했다. 부팅이 성공했어도 시스템은 맛이 갔겠지만 여기서부터 진행하면 된다.
이러고 부팅을 하면 veeam 리커버리 화면이 나오고 ssh로 접근 허용 할 건지 물어본다. 당연히 ssh로 하면 편하니까 ㅇㅋ해준다.
ssh로 접속하라고 계정명이랑 비밀번호, IP도 친절하게 알려주니 이걸로 접속함
ssh로 접속한 터미널에선 동의하라고 뜨니까 체크해준다. 안 해주면 다음으로 못 넘어감
신나게 다 깨부쉈으니 파일뿐만 아니라 볼륨을 살려야 시스템이 살아날 것이다. restore volumes로 간다.
볼륨 살리기를 클릭하니 잠깐 기다렸다가 어디서 살릴 건지 고르라는데 nfs를 해야 한다.
무려 내외부 2개의 오브젝트 스토리지에 저장이 되어 있긴 하나 직접 접근할 수가 없어 nfs로 해야 함
근데, nfs까지 날려먹어서 지금 이걸로 하면 당연히 안 된다 ㅎㅎ;
awscli로 nfs에서 minio랑 r2에 올렸었으니까 이번엔 다시 nfs로 그대로 옮긴다면? 그러면 된다.
다시 awscli를 쓰러 가자. 이번엔 R2에서 가져와 본다. 속도는 miniO보다 훨씬 느리다 다운로드나 업로드나
딱히 R2 쓰는 이유는 없고 사실 minio가 가까워서 더 빠르긴 한데 아까 ISO를 miniO에서 받아 써봤으니 R2로 한 번 써봄
겸사겸사 둘 다 모두 정상적으로 잘 작동하는 것도 확인할 수 있으니 이득
[root@storage ~]# aws s3 sync s3://disaster-recovery/nfs-data /nfs --profile r2
download: s3://disaster-recovery/nfs-data/2025-11-01-18-img/Info-OS-prober.txt to ../nfs/2025-11-01-18-img/Info-OS-prober.txt
download: s3://disaster-recovery/nfs-data/2025-11-01-18-img/Info-img-size.txt to ../nfs/2025-11-01-18-img/Info-img-size.txt
download: s3://disaster-recovery/nfs-data/2025-11-01-18-img/Info-lspci.txt to ../nfs/2025-11-01-18-img/Info-lspci.txt
download: s3://disaster-recovery/nfs-data/2025-11-01-18-img/dev-fs.list to ../nfs/2025-11-01-18-img/dev-fs.list
download: s3://disaster-recovery/nfs-data/2025-11-01-18-img/Info-lshw.txt to ../nfs/2025-11-01-18-img/Info-lshw.txt
download: s3://disaster-recovery/nfs-data/2025-11-01-18-img/Info-saved-by-cmd.txt to ../nfs/2025-11-01-18-img/Info-saved-by-cmd.txt
download: s3://disaster-recovery/nfs-data/2025-11-01-18-img/Info-packages.txt to ../nfs/2025-11-01-18-img/Info-packages.txt
...
download: s3://disaster-recovery/nfs-data/2025-11-01-18-img/almalinux_alma-root.xfs-ptcl-img.gz to ../nfs/2025-11-01-18-img/almalinux_alma-root.xfs-ptcl-img.gz
download: s3://disaster-recovery/nfs-data/veeam-recovery-amd64-6.0.0.iso.1 to ../nfs/veeam-recovery-amd64-6.0.0.iso.1
download: s3://disaster-recovery/nfs-data/veeam-recovery-amd64-6.0.0.iso to ../nfs/veeam-recovery-amd64-6.0.0.iso
download: s3://disaster-recovery/nfs-data/Alma veeam-snapshot/veeam-snapshot_2025-11-01T220425.vbk to ../nfs/Alma veeam-snapshot/veeam-snapshot_2025-11-01T220425.vbk
[root@storage ~]# ls /nfs/
2025-11-01-18-img 'Alma veeam-snapshot' veeam-recovery-amd64-6.0.0.iso veeam-recovery-amd64-6.0.0.iso.1그럼 다시 그대로 생긴 걸 확인 가능하다. 다시 복구 화면으로 가서 스냅샷 위치를 선택하면 된다 TUI라 매우 편하다.
현재 시스템이랑 백업본 안 내용을 보고 복구를 하면 되는데 다 할 거므로 디스크 하나씩 다 한다고 하고 스타트하면 됨
혹시 잘못해서 넘어가도 마지막으로 체크할 수 있으니 걱정 안 해도 됨 이제 제대로 됐으니 엔터로 복구 진행
다 완료됐다고 나오면 끄고 펌웨어랑 dvd드라이브를 원래대로 돌려놓고 시작하면 됨
사실 제대로 복구가 안 됐을까봐 살짝 쫄리긴 했음. 하지만...
[root@Alma ~]# veeamconfig --version
v6.3.2.1207
[root@Alma ~]# veeamconfig job list
Name ID Type Repository
veeam-snapshot {9d46b6fb-beb4-45b1-b6d2-cd76c9404838} All System Repository_1다시 복구하고 확인해보니 모든 게 그대로인 걸 확인이 가능했다! 이로써 데이터 뿐만이 아닌 장치 되살리기도 성공했다!
사실 hyper-V 환경이라 검사점이 있어서 이게 여기선 커버가 되지만 직접 서버랑 스토리지를 구성해서 할 수 있다는 걸 확인하고 싶었다.
그리고 veeam의 에이전트 말고 VBR 빔 백업 리커버리 서버 1대를 더 둬서 여러 노드에서 역할을 딱딱 정하고 하고 싶었지만
물리적인 한계로 인해 2대로 진행하게 됨. 그 결과 nfs서버랑 minio서버, awscli 쓰는 곳이 1대가 된 게 아쉽긴 함
'리눅스 > 실습' 카테고리의 다른 글
| 워드프레스 LEMP 서버 구축하기-1 (0) | 2025.11.07 |
|---|---|
| 리눅스 실습(4) - 프로세스와 자원 실습 (0) | 2025.11.02 |
| 리눅스 실습(3) - 파일시스템 실습(백업 스케쥴링과 이중화) (0) | 2025.11.01 |
| 리눅스 실습(3) - 파일시스템 실습(시스템 백업) (0) | 2025.11.01 |
| 리눅스 실습(3) - 파일시스템 실습(결함 허용과 데이터 스냅샷) (0) | 2025.11.01 |