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

소개

클라우드 서버의 백업은 매우 중요합니다. 단일 프로젝트를 실행하고 해당 데이터를 단일 서버에 저장하거나, 최소한의 로그를 유지하면서 Git에서 직접 VM에 배포하고 생성 및 해제되는 경우에도 실패 시나리오를 대비해야 합니다. 이는 사용 중인 응용 프로그램, 즉각적인 장애 조치가 얼마나 중요한지 및 예상되는 문제의 종류에 따라 많은 다른 의미를 갖을 수 있습니다.

이 안내서에서는 백업 및 데이터 중복성을 제공하는 다양한 접근 방식을 탐색합니다. 서로 다른 사용 사례에 따라 다른 해결책이 필요하기 때문에, 본 문서는 일반적인 해결책을 제공할 수는 없지만, 각 시나리오에서 중요한 요소와 작업에 가장 적합한 구현 방법을 알게 될 것입니다.

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

부분 1 – 중복 및 백업의 차이점은 무엇입니까?

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

중복성

데이터의 중복성은 시스템 문제가 발생한 경우 즉시 장애 극복을 의미합니다. 장애 극복이란 데이터 세트(또는 호스트) 중 하나가 사용 불가능해지면 즉시 다른 완벽한 사본이 제품으로 바뀌어 자리를 차지합니다. 이로 인해 거의 인식되지 않는 다운타임이 발생하며, 응용 프로그램 또는 웹 사이트는 마치 아무 일도 일어나지 않은 것처럼 요청을 계속 제공할 수 있습니다. 그동안 시스템 관리자(이 경우 당신)는 문제를 해결하고 시스템을 완전히 운영 가능한 상태로 복구할 수 있는 기회가 주어집니다.

그러나 중복성 솔루션은 일반적으로 백업 솔루션이 아닙니다. 중복된 저장소는 전체 장비 또는 시스템에 영향을 주는 장애에 대한 보호를 반드시 제공하지 않습니다. 예를 들어, 미러링된 RAID가 구성된 경우 (예: RAID 1), 데이터는 하나의 드라이브가 고장 나더라도 다른 드라이브가 여전히 사용 가능하기 때문에 중복됩니다. 그러나 장비 자체가 고장 나면 모든 데이터가 손실될 수 있습니다.

MySQL 그룹 복제와 같은 중복 해결책을 사용하면 일반적으로 데이터의 각 사본에서 모든 작업이 수행됩니다. 이에는 악의적 또는 실수로 인한 작업도 포함됩니다. 백업 솔루션은 데이터가 좋다고 알려진 이전 지점에서 복원할 수 있어야 합니다.

백업

일반적으로 중요한 데이터에 대한 기능적인 백업을 유지해야 합니다. 상황에 따라 응용 프로그램 또는 사용자 데이터, 또는 전체 웹 사이트 또는 기계의 백업을 의미할 수 있습니다. 백업의 아이디어는 시스템, 기계 또는 데이터 손실이 발생한 경우 데이터를 복원, 재배포 또는 기타 방법으로 액세스할 수 있어야 한다는 것입니다. 백업에서 복원하는 것은 다운 타임이 필요할 수 있지만 하루 전부터 시작하는 것과 처음부터 시작하는 것 사이의 차이를 만들 수 있습니다. 잃을 수 없는 것은 백업해야 합니다.

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

백업 자체로는 자동 장애 조치 기능을 제공하지 않습니다. 이는 백업이 100% 최신 상태인 경우 데이터 손실이 발생하지 않을 수 있지만 업타임이 손실될 수 있다는 것을 의미합니다. 이것이 왜 중복 및 백업이 종종 함께 사용되는 이유 중 하나입니다.

파일 수준 백업

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

cp 명령어 사용 방법

이론적으로 cp 명령어를 사용하여 Linux 서버와 같은 클라우드 서버를 백업할 수 있습니다. 이 명령어는 파일을 한 로컬 위치에서 다른 위치로 복사합니다. 로컬 컴퓨터에서는 제거 가능한 드라이브를 마운트한 다음 파일을 복사할 수 있습니다:

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

이 예제는 제거 가능한 디스크 sdc를 /mnt/my-backup으로 마운트하고 /etc 디렉토리를 디스크로 복사합니다. 그런 다음 드라이브를 마운트 해제하여 다른 위치에 저장할 수 있습니다.

Rsync 사용 방법

A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:

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

-azvP는 전형적인 Rsync 옵션 세트입니다. 각각의 기능을 살펴보면:

• a enables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the -rlptgoD options individually (yes, really). Notably, the -r option tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such as cp and scp.
• z compresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.
• v enables verbose mode, so you can read more details of your transfer while it is in progress.
• P tells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.

다른 rsync 옵션은 해당 매뉴얼 페이지에서 확인할 수 있습니다.

물론 클라우드 환경에서는 일반적으로 매번 마운트된 디스크에 파일을 마운트하고 복사하지 않습니다. Rsync는 SSH 스타일 구문을 제공하여 네트워크를 통해 원격 백업을 수행할 수도 있습니다. Rsync가 양쪽 끝에 모두 설치되어 있다면 SSH로 접속할 수 있는 모든 호스트에서 작동합니다. Rsync는 핵심 Linux 도구로 간주되기 때문에 대부분의 경우에는 안전한 가정입니다. 심지어 Mac이나 Windows 기계에서 지역적으로 작업 중이더라도 해당합니다.

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

이 작업은 로컬 머신의 /etc 디렉토리를 remote_host의 /backup 디렉토리로 백업합니다. 이 디렉토리에 쓰기 권한이 있고 사용 가능한 공간이 있다면 성공할 것입니다.

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

다른 백업 도구 사용 방법

비록 cp와 rsync는 유용하고 널리 쓰이지만, 그 자체로 완전한 솔루션은 아닙니다. Rsync를 사용하여 백업을 자동화하려면 자체 자동화 절차, 백업 일정, 로그 회전 등을 만들어야 합니다. 이는 외부 서비스를 사용하지 않는 매우 작은 배포 또는 매우 세부적인 스크립트를 유지하기 위해 전용 자원을 갖춘 매우 큰 배포에 적합할 수 있습니다. 그러나 많은 사용자는 전용 백업 솔루션에 투자하고 싶어할 것입니다.

Bacula

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

이를 통해 매우 세부적이고 유연한 구성이 가능합니다. 여러 클라이언트를 하나의 저장 장치로 백업하거나, 하나의 클라이언트를 여러 저장 장치로 백업하고, 노드를 추가하거나 세부 정보를 조정하여 백업 계획을 수정할 수 있습니다. 네트워크 환경에서 잘 작동하며 확장 가능하고 모듈식이므로 여러 서버에 걸쳐 있는 사이트 또는 응용 프로그램을 백업하는 데 탁월합니다.

Duplicity

Duplicity는 또 다른 오픈 소스 백업 도구입니다. 전송에 대해 기본적으로 GPG 암호화를 사용합니다.

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

GPG를 정기적으로 사용하지 않는 사람들에게는 분명히 보이지 않을 수도 있는 또 다른 이점은 각 거래가 완전히 정확한지 확인되어야 한다는 것입니다. GPG는 Rsync와 마찬가지로 해시 확인을 강제하여 전송 중 데이터 손실이 없었는지 확인합니다. 이는 백업에서 데이터를 복원할 때 파일 손상을 만날 가능성이 크게 줄어든다는 것을 의미합니다.

부분 3 — 블록 수준 백업

A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.

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

블록 수준 백업을 수행하기 위해 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

Part 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의 백업 기능은 이 서비스를 활성화한 드롭렛에 대해 정기적으로 자동 백업을 수행합니다. 이 서비스는 드롭렛 생성 시 “백업” 확인란을 확인하여 활성화할 수 있습니다:

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

시스템의 일회성 이미지 작성을 위해 스냅샷도 생성할 수 있습니다. 이러한 것들은 백업과 유사한 방식으로 작동하지만 자동화되지 않습니다. 어떤 상황에서는 실행 중인 시스템의 스냅샷을 취할 수 있지만 파일 시스템에 어떻게 쓰는지에 따라 권장되지 않을 수 있습니다:

디지털오션 백업 및 스냅샷에 대해 더 자세히 알아보세요. 컨테이너 및 이미지 문서에서.

GitOps

마지막으로, 각 서버별로 백업을 구현할 필요가 없는 경우가 있음을 언급할 가치가 있습니다. 예를 들어, 배포가 GitOps 원칙을 따른다면, 많은 개별 클라우드 서버를 일회용으로 취급하고 대신 Git 저장소와 같은 원격 데이터 소스를 데이터의 사실적인 원천으로 취급할 수 있습니다. 이러한 복잡하고 현대적인 배포는 많은 경우에 확장 가능하며 실패할 가능성이 적을 수 있습니다. 그러나 여전히 데이터 저장소 자체나 이러한 일회용 서버 각각이 정보를 보내는 중앙 로그 서버에 대한 백업 전략을 구현하고 싶을 것입니다. 배포의 어떤 측면이 백업할 필요가 없는지와 백업이 필요한지를 고려하십시오.

결론

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