limitless 2023-11

상용 백업솔루션으로 이미지 백업 후 복구를 진행합니다.
솔루션 마다 약간의 차이는 있지만 물리서버의 경우 에이전트 설치 후 리부팅 없이 운영하면서 백업을 진행합니다.

오랜만에 댓글 다네요.

ntkrnlmp 2023-11

로컬 디스크의 경우 LVM이나 ZFS 구성되어 있으면 snapshot 뜨고 그 snapshot을 저장하는 방식으로 하고, SAN의 경우 중앙에서 snapshot바로 뜹니다.

화란 2023-11

LVM, ZFS 둘다 미적용입니다. 말그대로 걍 순수(?) ext4로 하드 통으로 포맷했어요.

여긴어디 2023-11

RAID 카드 호환성 문제인지 DD의 경우 정상적으로 안되는 경우가 많아 acronis로 백업 및 복구 합니다.

화란 2023-11

True Image USB 부팅 방식인가요 ?

여긴어디 2023-11

네 가능합니다.
복구할때 acronis 부팅 이미지를 usb 혹은 cd로 만들어 부팅 후, 백업파일을 불러들여 진행하고 있습니다.

화란 2023-11

백업 할때도 acronis booting usb로 해야하는지요 ?

여긴어디 2023-11

네 맞습니다. 오래전 ghost 프로그램이라고 보시면 되구요. (IN,OUT 구성 방식이 ghost랑 똑같습니다.)
다른 백업 솔루션들도 많겠지만 저는 acronis가 가장 편해서 이것만 사용하고 있습니다.

ntkrnlmp 2023-11

Snapshot 없이 라이브 시스템의 드라이브 이미지를 dd 등으로 백업하는 것은 매우 위험한 행위입니다 (백업을 진행하는 도중 변경 사항이 발생함에 따라 파일시스템 테이블/저널과 데이터 블럭들의 일관성 유지 불가).

반드시 snapshot을 생성하고 그 snapshot을 백업하는 방식으로 진행해야 합니다 (volume manager 필수). Snapshot 생성이 불가능한 환경이라면 반드시 오프라인 백업을 진행해야 합니다.

화란 2023-11

아... 역시 장비 서비스 중단하고 백업하는게 가장 정확하군요 ㅠㅠ

엠브리오 2023-11

그렇쥬.
어차피 실시간으로 돌고 있는 서버를 백업하는 순간부터 디스크 엄청 읽어들이기 때문에 서비스를 제대로 하기 어렵습니다.

화란 2023-11

의견 감사합니다.

dateno1 2023-11

파일 시스템이 지원하는게 아닌 이상 무료 + 무중단은 힘듭니다

어차피 중요한 시스템이라면 메인 + 백업정돈 있을테니 교대로 중단시키면서 백업해주세요

화란 2023-11

의미 이해했습니다.

의견 고맙습니다.

상석하대 2023-11

파티션 별로 dump요.
복원은 restore로 하구요.
시스템을 중지할 필요없어요.
디스크나 볼륨을 통으로 뜨는 게 아니기 때문에 사용한 크기 만큼만 파일로 만들어 져요.
nfs, smb, ssh 등을 써서 다른 서버에 있는 저장소로 dump시켜도 돼요.
새 디스크가 원본보다 작아도 restore하면 복제한 거나 다름없어요.
HDD를 SSD로 바꿀 때도 좋아요.
레이드끼리, 레이드에서 단일 디스크로도 돼요.
단, 평소 시간이 있을 때 실제로 해보면서 매뉴얼을 만들어 놔야 유사시 복원에 헤매지 않아요.
리눅스의 배포판이나 버전에 따라 파티션별 dump와 restore가 꽤 달라서요.
fdisk나 parted를 인위적으로 해줘야 하며 label, grub을 손봐야 할 경우도 있어요.

화란 2023-11

파티션 별로 백업하는 방법도 고려한번 해보겠습니다.

그러나 우리동네(?)는 리눅스 만질줄 아는 사람이 별로 없어서 아마도 하드 통째로 백업하는 방식으로 가야할 것 같습니다 ^^

ntkrnlmp 2023-11

dump도 dd와 마찬가지입니다. 파일 수준에서 백업을 하는 것이 아닌 raw 파티션 이미지를 덤프하는 것이기 때문에 활동중인 파티션에 snapshot 없이 수행하면 일관성 문제가 발생합니다. 근본적으로 snapshot이 없이 라이브 시스템에 백업을 수행하는 것은 잘못된 백업 방법입니다.

상석하대 2023-11

데이터백업은 또 따로 해야죠.
답변은 재난상황 대비 및 유지보수를 전제했어요.
한편, 재난발생 시점과 마지막 백업 사이에 데이터 누수는 어쩔 수 없어요.
스냅샷이던 뭐든 말이죠.
그래도 누수를 줄이겠다면 백업 솔루션을 들여야지요.

송주환 2023-11

데이터 소실이 문제가 아니라, 파티션 이미지 자체가 깨질 수 있습니다. 그리고 데이터 무결성 문제는 생각하시는 것 보다 더 심각한 문제입니다. 파일이 아예 사라지면 낫죠, 만약 어떤 파일의 수정 사항이 일부만 반영된다면 어떻게 될까요? 그냥 재앙입니다.
그렇게 덤프하는 것은 백업이 아닙니다. 비즈니스 환경에 시한폭탄을 심는 일이죠.

dump 명령어는 어떠한 종류의 일관성도 보장하지 않습니다.

상석하대 2023-11

리눅스 OS disk 전체 백업 ? <--- 이게, 일상은 아니잖아요.
유지보수나 또는 한달 내지는 분기에 한번 정도 하잖습니까.
수시로 갱신되는 데이터 파일들은 주기를 짧게 잡아서 따로 백업하구요.
그리고 dump가 그렇게 허접하다면 하루에 몇 번씩도 하는 oracle, mysql 등의 데이터베이스는 남아나지 않겠는데요.
본질적으로 같은 거니까...

송주환 2023-11

본질적으로 같지 않습니다. 모든 DBMS의 테이블 덤프 도구는 추출 당시의 일관성을 보장하기 위한 메커니즘을 제공합니다.
예를 들어 expdp는 consistency 옵션과 flashback 옵션을 사용하여 데이터베이스 테이블을 덤프할 수 있습니다.

반면, 리눅스의 dump 명령어는 DB 테이블의 변경 상태가 어떠한지, 파일 시스템의 페이지 캐시가 flush 되었는지 신경 쓰지 않습니다. 그래서 위험하다는 것이구요. OS와 파일 시스템 동작에 대한 이해가 없으니 “그게 그거 아닌가?” 같은 말을 할 수 있는 것입니다.
데이터 무결성 문제와 RPO도 헷갈려 하시는 것 같은데, 여기까지 하시죠.

SiCMOS 2023-11

말씀하신 방법이 정상적으로 작동한다면 스냅샷 백업 솔루션들은 존재해지 않겠죠.
걔네들은 자체 드라이버에 에이전트까지 올려가며 스냅샷 생성하는데 일개 dump같은 유틸리티로 같은 동작은 불가능합니다.
솔루션 없이 일반적인 블록 백업을 할 경우 XFS의 경우 freeze 한 후 dump가 가능하고 다른 파일시스템들은 마운트 해제 후 오프라인으로 진행해야 합니다.

늪에가다 2023-11

Relax-and- recovery(ReaR) 로 하시면 됩니다.

흑기사 2023-11

tar cpf, tar xpf로 가능합니다 (물론 옮긴 후 부트로더 등록, 커널 파라미터, /etc/fstab 조정 필요)
다만 서비스 중단 안한 상태에서 했다가는 서버에 뭔 일 터질지 장담 못합니다.

화란 2023-11

서비스 내리고 한다. 명심하겠습니다.

제온프로 2023-11

전 DD로 하곤 합니다.
아주 느리게 해야 하요.. 파일 시스템이 손상되고나..
부트섹터에 문제가 생기기도 합니다.
DB는 항상 고려해야합니다.

달광이 2023-11

이게 사안을 좀 나눠봐야 할것 같은데요..

질문자의 질문이 애매했던 부분도 있는데
OS Disk자체를 백업하는 것만 본다면 dd로도 잘 백업될것 같은데..
1. OS Disk자체는 그저 부티용일 뿐이다.
2. OS Disk와 Mysql이나 db시스템등 서비스가 돌고 있다.

1의 경우라면 dd로도 잘 동작할것 같습니다. 단지 몇몇 로그가 조금 백업이 안되는 정도일 듯 하구요(시스템 업데이트 프로세스는 정지를 시켜놔야 합니다)
2의 경우라면 OS는 잘 백업되도 서비스는 백업이 힘들것 같습니다.

리눅스 OS특징을 봤을때 OS디스크만 백업하는건 큰 문제가 없을 듯 합니다.

화란 2023-11

Linux OS Disk 맞구요

여러 많은 분들의 의견처럼 장비끄고 백업/리스토어 솔루션으로 부팅해서 작업하는 걸로 결정했습니다^^ // DD도 병행해서요

의견 고맙습니다!

상석하대 2023-11

어이가 없어요.
OS를 백업하는 방법중에 하나인 dump가지고 모욕 당해서요.
OS백업!?
한 때 골치였어요.
라이브로 하는 cat, dd는 시스템에 무리를 주고,
클론툴은 시스템을 중단해야 하며,
백업솔루션은 배보다 배꼽이 더 큰 가격이 부담되고,
Bacula 같은 오픈소스 활용도 추가 인프라를 필요로 하고,
스냅샷으로는 디스크 자체 고장을 대비할 수 없는 등으로 인해서요.
적잖은 시행착오 끝에 dump로 자리 잡았어요.
별도로 추가한 디스크나 네트워크 상의 다른 공간으로 주기적으로 dump하고 있어요.
한달 또는 분기에 한번 정도로 해서요.
OS는 자주할 필요가 없어요.
OS를 제외한 데이터 파일들은 따로 tar, rsync를 쓰는 거구요.
이제는 서버구축시 파티션 dump설정을 아예 기본으로 넣어요.
dump했다고 시스템이 멈춘적은 여태 없었어요.
dump실행 후 어느 파티션이 깨졌다든가 파일 지워졌다든가 이런거 없어요.
그냥 따박따박 파티션별로 백업본 몇개씩 남겨두면서 잘 순환되고 있어요.
수많은 서버가 몇년 동안이요.
종종 디스크 교체, 파일시스템 문제로 부팅불능 조치, 데이터복사, 랜섬웨어복구 등에 dump 파일을 이용했어요.
dump에 들어 있는 OS용 파일만 가지고 restore 과정없이 엎어치고 매쳐서라도 시스템을 복원할 수 있는 거구요.
그래서 dump를 권장했어요.
단순 명쾌한 일종에 복사 도구인 dump를 가지고 무슨 일관성, 무결성이 어쩌고 하는지 그 자체가 수긍이 안되는 거예요.
게다가 이해가 있니 없니, 헷갈리니 하는 말까지 듣구요.
함부로 쓸 말이 아니라는 거 알지요.
유용한 도구일 뿐, 그 이상도 이하도 아닌 걸 가지고 말이죠.