백업

데이터 백업은 컴퓨터나 데이터베이스에 저장된 데이터를 원본과 분리된 위치에 복사해 두었다가, 손상·삭제·장애가 생겼을 때 다시 사용할 수 있게 하는 절차다.^[1][2] 단순히 파일을 한 번 더 저장하는 행위가 아니라, 원본이 손상되더라도 다시 출발할 수 있게 만드는 준비 과정에 가깝다.^[1]

백업된 사본은 클라우드 같은 원격 저장소, 별도의 장비, 또는 다른 운영 환경에 나눠 둘 수 있다.^[1] 저장 위치를 분리해 두면 한 지점의 장애가 곧바로 전체 손실로 이어질 가능성을 줄일 수 있다.^[2]

랜섬웨어, 사이버 공격, 해킹은 데이터의 무결성을 손상시키거나 접근을 막을 수 있다.^[3] 여기에 하드웨어 고장이나 자연재해가 겹치면 저장 매체 자체가 더 이상 쓸 수 없는 상태가 된다.^[3]

데이터 손실은 기술 문제만이 아니다. 중요한 파일을 실수로 지우는 일도 흔하며, 이런 사고는 디지털 자산 전체에 영향을 줄 수 있다.^[3] 그래서 백업은 개인 자료 보관을 넘어서 비즈니스 연속성을 떠받치는 기본 수단으로 취급된다.^[3]

복제는 여러 시스템이 같은 데이터를 거의 동시에 유지하도록 하는 방식이고, 백업은 특정 시점의 데이터를 별도로 저장해 나중에 되돌릴 수 있게 하는 방식이다.^[2] 둘 다 가용성을 높이지만, 목적은 같지 않다.^[2]

복제는 서비스가 계속 돌아가도록 돕는 쪽에 가깝고, 백업은 사고가 난 뒤에 원상 복구할 수 있게 하는 쪽에 가깝다.^[2] 따라서 실제 운영에서는 두 방식을 함께 두고, 서비스 지속성과 복구 가능성을 따로 관리하는 편이 안정적이다.^[2]

가장 널리 알려진 원칙은 3-2-1 백업 전략이다.^[3] 원본을 포함해 최소 3개의 사본을 유지하고, 2종류 이상의 저장 매체를 사용하며, 그중 1개는 원격지에 두는 방식이다.^[3]

이 원칙의 핵심은 단일 실패 지점을 없애는 데 있다.^[3] 같은 장소, 같은 장비, 같은 장애 유형에만 의존하지 않도록 배치를 나누면 복구 성공률을 높이기 쉽다.^[1][3]

클라우드 환경에서는 백업 정보와 복원 절차를 함께 설계해야 한다.^[4] 예를 들어 Cloud DB for MySQL의 백업 기능은 서버별 백업 정보를 확인하고, 보관된 백업 파일로 복원을 수행하는 흐름을 제공한다.^[4]

고가용성 설정 서버뿐 아니라 Stand Alone Server에서도 백업 및 복원 기능을 쓸 수 있지만, 시점 복원 지원 여부는 환경에 따라 다를 수 있다.^[4] 그래서 운영자는 백업 주기만 볼 것이 아니라, 실제로 어디까지 되돌릴 수 있는지까지 함께 확인해야 한다.^[4]

백업은 저장하는 것만으로 끝나지 않는다.^[1] 실제 복구가 가능한지, 복원 후 데이터가 기대한 상태인지, 운영 중단 시간을 얼마나 줄일 수 있는지를 주기적으로 점검해야 한다.^[2]

그래서 백업 정책은 보관 기간, 복원 대상, 검증 주기를 함께 정하는 편이 좋다.^[1][2] 이런 점검이 있어야 백업이 단순한 사본 보관이 아니라 실제 복구 수단으로 기능한다.^[3]

백업은 데이터 보안과 데이터 보호를 함께 읽을 때 더 잘 연결된다.^[2] 실제 운영 맥락은 데이터센터, 데이터베이스, 랜섬웨어, 사이버 공격, 비즈니스, 복원 같은 항목과도 맞물린다.

• 데이터 보안
• 데이터 보호
• 데이터센터
• 데이터베이스
• 랜섬웨어
• 사이버 공격
• 비즈니스
• 복원

^[1] Ccloudian.com(새 탭에서 열림)

^[2] Llearn.microsoft.com(새 탭에서 열림)

^[3] Eexperience.dropbox.com(새 탭에서 열림)

^[4] Gguide.ncloud-docs.com(새 탭에서 열림)