효과적인 백업 전략을 선택하는 방법

소개

백업은 클라우드 서버에 매우 중요합니다. 모든 데이터가 단일 서버에 저장된 단일 프로젝트를 실행하든, 최소한의 로그 집합을 유지하면서 회전 및 해체되는 VM에 Git에서 직접 배포하든, 항상 실패 시나리오를 계획해야 합니다. 이는 사용 중인 애플리케이션, 즉각적인 장애 복구가 얼마나 중요한지, 예상되는 문제의 종류에 따라 많은 다른 의미를 가질 수 있습니다.

이 가이드에서는 백업 및 데이터 중복성을 제공하기 위한 다양한 접근 방식을 살펴봅니다. 사용 사례마다 다른 솔루션이 필요하기 때문에 이 문서에서는 모든 경우에 맞는 답을 제공할 수는 없지만 다양한 시나리오에서 무엇이 중요한지, 작업에 가장 적합한 구현은 무엇인지 배우게 됩니다.

이 가이드의 첫 번째 부분에서는 환경에 맞는 접근 방식을 선택할 수 있도록 여러 백업 솔루션을 살펴보고 각 솔루션의 상대적 장점을 검토합니다. 2부에서는 중복 옵션을 살펴봅니다.

1부 - 중복과 백업의 차이점은 무엇입니까?

중복 및 백업이라는 용어의 정의는 종종 중복되며 많은 경우 혼동됩니다. 이들은 관련이 있지만 다른 두 가지 별개의 개념입니다. 일부 솔루션은 두 가지를 모두 제공합니다.

중복성

데이터 중복성은 시스템 문제 발생 시 즉각적인 장애 조치가 있음을 의미합니다. 페일오버는 한 데이터 집합(또는 한 호스트)을 사용할 수 없게 되면 다른 완벽한 복사본이 즉시 프로덕션으로 교체되어 그 자리를 대신하는 것을 의미합니다. 이로 인해 인지할 수 있는 가동 중지 시간이 거의 없으며 응용 프로그램이나 웹 사이트는 아무 일도 없었던 것처럼 요청을 계속 처리할 수 있습니다. 그동안 시스템 관리자(이 경우 귀하)는 문제를 해결하고 시스템을 완전한 작동 상태로 되돌릴 수 있습니다.

그러나 중복 솔루션은 일반적으로 백업 솔루션이 아닙니다. 중복 스토리지는 전체 기계 또는 시스템에 영향을 미치는 오류에 대한 보호를 반드시 제공하지는 않습니다. 예를 들어 미러링된 RAID(예: RAID 1)를 구성한 경우 하나의 드라이브에 장애가 발생해도 다른 드라이브는 계속 사용할 수 있다는 점에서 데이터가 중복됩니다. 그러나 시스템 자체에 오류가 발생하면 모든 데이터가 손실될 수 있습니다.

MySQL 그룹 복제와 같은 중복 솔루션을 사용하면 일반적으로 모든 작업이 모든 데이터 복사본에서 수행됩니다. 여기에는 악의적이거나 우발적인 작업이 포함됩니다. 기본적으로 백업 솔루션은 데이터가 양호하다고 알려진 이전 지점에서 복원할 수도 있어야 합니다.

지원

일반적으로 중요한 데이터에 대한 기능 백업을 유지 관리해야 합니다. 상황에 따라 애플리케이션이나 사용자 데이터 또는 전체 웹사이트나 시스템을 백업해야 할 수도 있습니다. 백업의 기본 개념은 시스템, 시스템 또는 데이터 손실이 발생한 경우 데이터를 복원, 재배포 또는 액세스할 수 있다는 것입니다. 백업에서 복원하려면 가동 중지 시간이 필요할 수 있지만 하루 전에 시작하는 것과 처음부터 시작하는 것의 차이를 의미할 수 있습니다. 손실을 감당할 수 없는 모든 것은 기본적으로 백업해야 합니다.

방법 측면에서 보면 백업에는 여러 가지 수준이 있습니다. 다른 종류의 문제를 설명하기 위해 필요에 따라 계층화할 수 있습니다. 예를 들어 문제가 발생할 경우 이전 설정으로 되돌릴 수 있도록 수정하기 전에 구성 파일을 백업할 수 있습니다. 이는 적극적으로 모니터링하는 작은 변경 사항에 이상적입니다. 그러나 이 설정은 디스크 오류 또는 더 복잡한 경우 실패합니다. 또한 원격 위치에 대한 정기적인 자동 백업이 있어야 합니다.

백업 자체는 자동 장애 조치를 제공하지 않습니다. 즉, 오류로 인해 데이터 비용이 발생하지 않을 수 있지만(백업이 100% 최신 상태라고 가정) 가동 시간이 발생할 수 있습니다. 이것이 중복성과 백업이 종종 서로 조합되어 사용되는 이유 중 하나입니다.

2부 - 파일 수준 백업

가장 친숙한 백업 형식 중 하나는 파일 수준 백업입니다. 이 유형의 백업은 일반적인 파일 시스템 수준 복사 도구를 사용하여 파일을 다른 위치나 장치로 전송합니다.

cp 명령을 사용하는 방법

이론적으로 cp 명령을 사용하여 클라우드 서버와 같은 Linux 시스템을 백업할 수 있습니다. 이것은 한 로컬 위치에서 다른 위치로 파일을 복사합니다. 로컬 컴퓨터에서 이동식 드라이브를 마운트한 다음 여기에 파일을 복사할 수 있습니다.

mount /dev/sdc /mnt/my-backup
cp -a /etc/* /mnt/my-backup
umount /dev/sdc

이 예에서는 이동식 디스크 sdc를 /mnt/my-backup으로 마운트한 다음 /etc 디렉터리를 디스크에 복사합니다. 그런 다음 다른 곳에 저장할 수 있는 드라이브를 마운트 해제합니다.

Rsync 사용 방법

cp에 대한 더 나은 대안은 rsync 명령입니다. Rsync는 내장된 체크섬 유효성 검사 및 기타 기능을 통해 다양한 환경에서 파일 및 디렉터리를 복제하기 위한 다양한 옵션을 제공하는 강력한 도구입니다. Rsync는 다음과 같이 위의 cp 작업과 동일한 작업을 수행할 수 있습니다.

mount /dev/sdc /mnt/my-backup
rsync -azvP /etc/* /mnt/my-backup
umount /dev/sdc

-azvP는 일반적인 Rsync 옵션 세트입니다. 각각의 기능을 분석하면 다음과 같습니다.

• a는 파일 수정 시간, 소유자 등을 보존하는 이 복사 작업에 대해 "아카이브 모드\를 활성화합니다. 또한 각 -rlptgoD 를 제공하는 것과 같습니다. 옵션을 개별적으로(예, 정말). 특히 -r 옵션은 Rsync가 중첩된 파일 및 폴더도 복사하기 위해 하위 디렉터리로 재귀하도록 지시합니다. 이 옵션은 다음과 같은 다른 많은 복사 작업에 공통적입니다. cp 및 scp로.
• z는 가능한 경우 전송 자체 중에 데이터를 압축합니다. 이는 특히 로그 및 기타 텍스트와 같이 매우 효과적으로 압축되는 데이터를 전송할 때 느린 연결을 통한 전송에 유용합니다.
• v는 자세한 정보 표시 모드를 활성화하므로 진행 중인 전송에 대한 자세한 내용을 읽을 수 있습니다.
• P는 나중에 전송을 재개할 수 있도록 완전히 전송되지 않은 파일의 부분 복사본을 유지하도록 Rsync에 지시합니다.

매뉴얼 페이지에서 다른 rsync 옵션을 검토할 수 있습니다.

물론 클라우드 환경에서는 일반적으로 매번 마운트된 디스크에 파일을 마운트하고 복사하지 않습니다. Rsync는 SSH 스타일 구문을 제공하여 네트워크를 통해 원격 백업을 수행할 수도 있습니다. 이것은 Rsync가 양쪽 끝에 설치되어 있는 한 SSH를 통해 연결할 수 있는 모든 호스트에서 작동합니다. Rsync는 핵심 Linux 도구로 간주되기 때문에 Mac 또는 Windows 시스템에서 로컬로 작업하는 경우에도 거의 항상 안전한 가정입니다.

rsync -azvP /etc/* username@remote_host:/backup/

그러면 로컬 시스템의 /etc 디렉토리가 /backup에 있는 remote_host의 디렉토리에 백업됩니다. 이 디렉토리에 쓸 수 있는 권한이 있고 사용 가능한 공간이 있으면 성공합니다.

Rsync를 사용하여 로컬 및 원격 디렉터리를 동기화하는 방법에 대한 자세한 정보를 검토할 수도 있습니다.

다른 백업 도구를 사용하는 방법

cp 및 rsync는 유용하고 어디에나 있지만 그 자체로는 완전한 솔루션이 아닙니다. Rsync를 사용하여 백업을 자동화하려면 자체 자동화 절차, 백업 일정, 로그 회전 등을 만들어야 합니다. 이는 외부 서비스를 사용하지 않으려는 일부 매우 작은 배포 또는 다양한 목적을 위해 매우 세분화된 스크립트를 유지하기 위한 전용 리소스가 있는 대규모 배포에 적합할 수 있지만 많은 사용자가 전용 백업 제품에 투자하기를 원할 수 있습니다.

바큘라

Bacula는 클라이언트-서버 모델에서 작동하는 복잡하고 유연한 솔루션입니다. Bacula는 클라이언트, 백업 위치 및 디렉터(실제 백업을 조정하는 구성 요소)라는 별도의 개념으로 설계되었습니다. 또한 각 백업 작업을 "작업\이라는 단위로 구성합니다.

이를 통해 매우 세분화되고 유연한 구성이 가능합니다. 여러 클라이언트를 하나의 저장 장치에 백업하고 하나의 클라이언트를 여러 저장 장치에 백업하고 노드를 추가하거나 세부 정보를 조정하여 백업 구성표를 수정할 수 있습니다. 네트워크 환경에서 잘 작동하고 확장 가능하고 모듈식이므로 여러 서버에 분산된 사이트 또는 애플리케이션을 백업하는 데 적합합니다.

이중성

이중성은 또 다른 오픈 소스 백업 도구입니다. 기본적으로 전송에 GPG 암호화를 사용합니다.

파일 백업에 GPG 암호화를 사용하는 명백한 이점은 데이터가 일반 텍스트로 저장되지 않는다는 것입니다. GPG 키 소유자만 데이터를 해독할 수 있습니다. 이는 데이터가 여러 위치에 저장될 때 필요한 추가 보안 조치를 상쇄하는 일정 수준의 보안을 제공합니다.

GPG를 정기적으로 사용하지 않는 사람들에게 분명하지 않을 수 있는 또 다른 이점은 각 거래가 완전히 정확한지 확인해야 한다는 것입니다. Rsync와 같은 GPG는 전송 중에 데이터 손실이 없도록 해시 검사를 시행합니다. 즉, 백업에서 데이터를 복원할 때 파일 손상이 발생할 가능성이 훨씬 줄어듭니다.

3부 - 블록 수준 백업

약간 덜 일반적이지만 파일 수준 백업에 대한 중요한 대안은 블록 수준 백업입니다. 이 백업 스타일은 전체 장치를 복제하고 복원하는 데 사용할 수 있기 때문에 "이미징\이라고도 합니다. 블록 수준 백업을 사용하면 파일보다 더 깊은 수준에서 복사할 수 있습니다. 파일 기반 백업은 file1을 복사할 수 있지만 file2 및 file3을 백업 위치에 저장하는 경우 블록 기반 백업 시스템은 해당 파일이 상주하는 전체 "블록\을 복사합니다. 동일한 개념을 설명하는 또 다른 방법은 블록 수준 백업이 비트마다 정보를 복사한다고 말하는 것입니다. 그들은 해당 비트에 걸쳐 있을 수 있는 파일에 대해 알지 못합니다.

블록 수준 백업의 장점 중 하나는 일반적으로 더 빠르다는 것입니다. 파일 기반 백업은 일반적으로 각각의 개별 파일에 대해 새로운 전송을 시작하지만 블록 기반 백업은 블록을 전송하므로 복사를 완료하기 위해 시작해야 하는 비순차적 전송이 더 적습니다.

dd를 사용하여 블록 수준 백업 수행

블록 수준 백업을 수행하는 가장 일반적인 방법은 dd 유틸리티를 사용하는 것입니다. dd는 전체 디스크 이미지를 생성하는 데 사용할 수 있으며 CD 또는 DVD와 같은 이동식 미디어를 보관할 때도 자주 사용됩니다. 즉, 예비 단계 없이 파티션이나 디스크를 단일 파일 또는 원시 장치에 백업할 수 있습니다.

dd를 사용하려면 다음과 같이 입력 위치와 출력 위치를 지정해야 합니다.

dd if=/path/of/original/device of=/path/to/place/backup

이 시나리오에서 if= 인수는 입력 장치 또는 위치를 지정합니다. of= 인수는 출력 파일 또는 위치를 지정합니다. 혼동하지 않도록 주의하십시오. 그렇지 않으면 실수로 전체 디스크를 지울 수 있습니다.

예를 들어 /dev/sda3에 있는 문서가 포함된 파티션을 백업하려면 .img 파일:

dd if=/dev/sda3 of=~/documents.img

4부 - 백업 버전 관리

데이터를 백업하는 주요 동기 중 하나는 원치 않는 변경이나 삭제가 발생한 경우 파일의 이전 버전을 복원할 수 있기 때문입니다. 지금까지 언급한 모든 백업 메커니즘이 이를 제공할 수 있지만 보다 세분화된 솔루션을 구현할 수도 있습니다.

예를 들어 이를 수행하는 수동 방법은 nano에서 파일을 편집하기 전에 파일의 백업을 만드는 것입니다.

cp file1 file1.bak
nano file1

편집기로 파일을 수정할 때마다 타임스탬프가 있는 숨겨진 파일을 생성하여 이 프로세스를 자동화할 수도 있습니다. 예를 들어 이것을 ~/.bashrc 파일에 배치하여 bash에서 nano를 실행할 때마다(즉, >$) 셸에서 연도(%y), 월(%m), 일(%d) 등:

nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }

이것은 nano를 사용하여 파일을 수동으로 편집하는 정도까지 작동하지만 범위가 제한되어 디스크를 빠르게 채울 수 있습니다. 편집하려는 파일을 수동으로 복사하는 것보다 더 나빠질 수 있음을 알 수 있습니다.

이 설계에 내재된 많은 문제를 해결하는 대안은 Git을 버전 제어 시스템으로 사용하는 것입니다. 주로 일반 텍스트(일반적으로 소스 코드) 버전 관리에 중점을 두고 개발되었지만 Git을 사용하여 거의 모든 종류의 파일을 추적할 수 있습니다. 자세히 알아보려면 Git을 효과적으로 사용하는 방법을 검토하세요.

5부 - 서버 수준 백업

대부분의 호스팅 제공업체는 자체 선택적 백업 기능도 제공합니다. DigtalOcean의 백업 기능은 이 서비스를 활성화한 물방울에 대한 자동 백업을 정기적으로 수행합니다. 드롭릿 생성 중에 "백업\ 확인란을 선택하여 이 기능을 켤 수 있습니다.

이렇게 하면 전체 클라우드 서버 이미지가 정기적으로 백업됩니다. 이는 백업에서 재배포하거나 새 드롭릿의 기반으로 사용할 수 있음을 의미합니다.

시스템의 일회성 이미징을 위해 스냅샷을 생성할 수도 있습니다. 이는 백업과 유사한 방식으로 작동하지만 자동화되지는 않습니다. 일부 상황에서는 실행 중인 시스템의 스냅샷을 찍을 수 있지만 파일 시스템에 쓰는 방법에 따라 항상 권장되는 것은 아닙니다.

컨테이너 및 이미지 설명서에서 DigitalOcean 백업 및 스냅샷에 대해 자세히 알아볼 수 있습니다.

GitOps

마지막으로 서버별로 백업을 구현하지 않아도 되는 상황이 있다는 점에 유의해야 합니다. 예를 들어 배포가 GitOps의 원칙을 따르는 경우 많은 개별 클라우드 서버를 일회용으로 취급하고 대신 Git 리포지토리와 같은 원격 데이터 소스를 데이터의 효과적인 원본으로 취급할 수 있습니다. 이와 같이 복잡하고 현대적인 배포는 많은 경우 확장성이 뛰어나고 실패할 가능성이 적습니다. 그러나 데이터 저장소 자체 또는 이러한 각 일회용 서버가 정보를 보낼 수 있는 중앙 집중식 로그 서버에 대한 백업 전략을 구현하고자 할 것입니다. 배포의 어떤 측면을 백업할 필요가 없는지, 어떤 측면을 백업해야 하는지 고려하십시오.

결론

이 기사에서는 다양한 백업 개념과 솔루션을 살펴보았습니다. 다음으로 중복성을 활성화하는 솔루션을 검토할 수 있습니다.