1901;팔리면 1656;문Ȣ16;1648; 맙시다. 소1473;한 NJ13;변 댓글1012; 삭1228;Ȣ16;lj16;,148; ǥ12;-124;러운 1068; 1077;니다 
실무에서 리눅스 OS disk 1204;체 0177;업할ǐ12; 1452;/196; Ǻ12;떤식1004;/196; Ȣ16;나요 ?
클론1656;라.iso/196; ǥ12;ᔚ1;해서 disk to image / disk to disk 복1228; Ȣ16;lj16;,148; 1109;비를 1104;시 1473;단Ȣ16;고 해야해서, 1109;비를 1473;단Ȣ16;1648; 않고 Ȣ16;lj16;,152; 찾습니다.
dd if=/dev/sdx of=/image.dd
tar 명/161;Ǻ12;...
1060;런식1004;/196; 많1060;들 Ǹ16;시나요 ?
아니면 Ǻ12;떤 0169;식1012; 1452;/196; Ǹ16;lj16;가요 ?
// 서명
솔루션 마다 약간의 차이는 있지만 물리서버의 경우 에이전트 설치 후 리부팅 없이 운영하면서 백업을 진행합니다.
오랜만에 댓글 다네요.
복구할때 acronis 부팅 이미지를 usb 혹은 cd로 만들어 부팅 후, 백업파일을 불러들여 진행하고 있습니다.
다른 백업 솔루션들도 많겠지만 저는 acronis가 가장 편해서 이것만 사용하고 있습니다.
반드시 snapshot을 생성하고 그 snapshot을 백업하는 방식으로 진행해야 합니다 (volume manager 필수). Snapshot 생성이 불가능한 환경이라면 반드시 오프라인 백업을 진행해야 합니다.
어차피 실시간으로 돌고 있는 서버를 백업하는 순간부터 디스크 엄청 읽어들이기 때문에 서비스를 제대로 하기 어렵습니다.
어차피 중요한 시스템이라면 메인 + 백업정돈 있을테니 교대로 중단시키면서 백업해주세요
의견 고맙습니다.
복원은 restore로 하구요.
시스템을 중지할 필요없어요.
디스크나 볼륨을 통으로 뜨는 게 아니기 때문에 사용한 크기 만큼만 파일로 만들어 져요.
nfs, smb, ssh 등을 써서 다른 서버에 있는 저장소로 dump시켜도 돼요.
새 디스크가 원본보다 작아도 restore하면 복제한 거나 다름없어요.
HDD를 SSD로 바꿀 때도 좋아요.
레이드끼리, 레이드에서 단일 디스크로도 돼요.
단, 평소 시간이 있을 때 실제로 해보면서 매뉴얼을 만들어 놔야 유사시 복원에 헤매지 않아요.
리눅스의 배포판이나 버전에 따라 파티션별 dump와 restore가 꽤 달라서요.
fdisk나 parted를 인위적으로 해줘야 하며 label, grub을 손봐야 할 경우도 있어요.
그러나 우리동네(?)는 리눅스 만질줄 아는 사람이 별로 없어서 아마도 하드 통째로 백업하는 방식으로 가야할 것 같습니다 ^^
답변은 재난상황 대비 및 유지보수를 전제했어요.
한편, 재난발생 시점과 마지막 백업 사이에 데이터 누수는 어쩔 수 없어요.
스냅샷이던 뭐든 말이죠.
그래도 누수를 줄이겠다면 백업 솔루션을 들여야지요.
그렇게 덤프하는 것은 백업이 아닙니다. 비즈니스 환경에 시한폭탄을 심는 일이죠.
dump 명령어는 어떠한 종류의 일관성도 보장하지 않습니다.
유지보수나 또는 한달 내지는 분기에 한번 정도 하잖습니까.
수시로 갱신되는 데이터 파일들은 주기를 짧게 잡아서 따로 백업하구요.
그리고 dump가 그렇게 허접하다면 하루에 몇 번씩도 하는 oracle, mysql 등의 데이터베이스는 남아나지 않겠는데요.
본질적으로 같은 거니까...
예를 들어 expdp는 consistency 옵션과 flashback 옵션을 사용하여 데이터베이스 테이블을 덤프할 수 있습니다.
반면, 리눅스의 dump 명령어는 DB 테이블의 변경 상태가 어떠한지, 파일 시스템의 페이지 캐시가 flush 되었는지 신경 쓰지 않습니다. 그래서 위험하다는 것이구요. OS와 파일 시스템 동작에 대한 이해가 없으니 “그게 그거 아닌가?” 같은 말을 할 수 있는 것입니다.
데이터 무결성 문제와 RPO도 헷갈려 하시는 것 같은데, 여기까지 하시죠.
걔네들은 자체 드라이버에 에이전트까지 올려가며 스냅샷 생성하는데 일개 dump같은 유틸리티로 같은 동작은 불가능합니다.
솔루션 없이 일반적인 블록 백업을 할 경우 XFS의 경우 freeze 한 후 dump가 가능하고 다른 파일시스템들은 마운트 해제 후 오프라인으로 진행해야 합니다.
다만 서비스 중단 안한 상태에서 했다가는 서버에 뭔 일 터질지 장담 못합니다.
아주 느리게 해야 하요.. 파일 시스템이 손상되고나..
부트섹터에 문제가 생기기도 합니다.
DB는 항상 고려해야합니다.
질문자의 질문이 애매했던 부분도 있는데
OS Disk자체를 백업하는 것만 본다면 dd로도 잘 백업될것 같은데..
1. OS Disk자체는 그저 부티용일 뿐이다.
2. OS Disk와 Mysql이나 db시스템등 서비스가 돌고 있다.
1의 경우라면 dd로도 잘 동작할것 같습니다. 단지 몇몇 로그가 조금 백업이 안되는 정도일 듯 하구요(시스템 업데이트 프로세스는 정지를 시켜놔야 합니다)
2의 경우라면 OS는 잘 백업되도 서비스는 백업이 힘들것 같습니다.
리눅스 OS특징을 봤을때 OS디스크만 백업하는건 큰 문제가 없을 듯 합니다.
여러 많은 분들의 의견처럼 장비끄고 백업/리스토어 솔루션으로 부팅해서 작업하는 걸로 결정했습니다^^ // DD도 병행해서요
의견 고맙습니다!
OS를 백업하는 방법중에 하나인 dump가지고 모욕 당해서요.
OS백업!?
한 때 골치였어요.
라이브로 하는 cat, dd는 시스템에 무리를 주고,
클론툴은 시스템을 중단해야 하며,
백업솔루션은 배보다 배꼽이 더 큰 가격이 부담되고,
Bacula 같은 오픈소스 활용도 추가 인프라를 필요로 하고,
스냅샷으로는 디스크 자체 고장을 대비할 수 없는 등으로 인해서요.
적잖은 시행착오 끝에 dump로 자리 잡았어요.
별도로 추가한 디스크나 네트워크 상의 다른 공간으로 주기적으로 dump하고 있어요.
한달 또는 분기에 한번 정도로 해서요.
OS는 자주할 필요가 없어요.
OS를 제외한 데이터 파일들은 따로 tar, rsync를 쓰는 거구요.
이제는 서버구축시 파티션 dump설정을 아예 기본으로 넣어요.
dump했다고 시스템이 멈춘적은 여태 없었어요.
dump실행 후 어느 파티션이 깨졌다든가 파일 지워졌다든가 이런거 없어요.
그냥 따박따박 파티션별로 백업본 몇개씩 남겨두면서 잘 순환되고 있어요.
수많은 서버가 몇년 동안이요.
종종 디스크 교체, 파일시스템 문제로 부팅불능 조치, 데이터복사, 랜섬웨어복구 등에 dump 파일을 이용했어요.
dump에 들어 있는 OS용 파일만 가지고 restore 과정없이 엎어치고 매쳐서라도 시스템을 복원할 수 있는 거구요.
그래서 dump를 권장했어요.
단순 명쾌한 일종에 복사 도구인 dump를 가지고 무슨 일관성, 무결성이 어쩌고 하는지 그 자체가 수긍이 안되는 거예요.
게다가 이해가 있니 없니, 헷갈리니 하는 말까지 듣구요.
함부로 쓸 말이 아니라는 거 알지요.
유용한 도구일 뿐, 그 이상도 이하도 아닌 걸 가지고 말이죠.