백업(Backup)과 복구(Recovery)

  • Mysql 8.4를 기준으로 작성했습니다.

백업의 유형

백업은 여러가지 기준에 따라 유형으로 나뉩니다.

  • 백업 방식: 물리적 / 논리적
  • 백업 대상: 전체 백업 / 증분 백업
  • 서버 상태: 로컬 백업 / 서버 백업
  • 백업 장소: 온라인 백업 / 오프라인 백업

물리적 백업과 논리적 백업

  • 물리적 백업(Physical Backup)
    • 개념
      • 데이터베이스 파일과 디렉토리를 원본 그대로 복사하여 백업하는 방식입니다.
    • 특징
      • 하드웨어에 종속적
        • 복구는 동일하거나 유사한 하드웨어 특성을 갖춘 곳에만 가능합니다.
        • 동일한 서버 환경을 구성시 사용하기 좋습니다.
      • 빠른 속도
        • 파일과 디렉토리를 그대로 복사하기 때문에, 백업과 복구시 따로 변환 과정이 없어 빠릅니다.
        • 대용량의 데이터에 대해 백업 및 복구할 때 사용하기 좋습니다.
      • 주의점
        • 서버가 운영 중 이라면, 백업 중 내용을 변경하지 못하도록 잠금한 후 진행해야합니다.
        • 실행중이지 않다면 바로 진행할 수 있습니다.
      • DB 외에도 관련 파일(로그나 구성 파일등)이 포함될 수 있습니다.
      • mysqlbackup이나 파일 복사 명령어(cp, scp, tar, rsync 등)를 통해 백업할 수 있습니다.
      • 같은 설정과 로그 상태를 재현: DB 외에도 관련 파일(로그나 구성 파일등)이 포함될 수 있습니다.
        • 로그: MySQL 에러 로그 등, 구성 파일: MySQL 설정 파일(my.cnf 등)
  • 논리적 백업
    • 개념
      • 논리적 DB구조(CREATE DATABASE, CREATE TABLE)와 내용(INSERT, 구분된 텍스트 파일)으로 표현된 정보를 저장 하는 방식입니다.
    • 특징
      • 높은 휴대성
        • 명령어를 다시 실행하는 방식으로 진행되기 때문에, 하드웨어에 종속되지 않습니다.
        • 다른 하드웨어, 운영체제로 이관시 사용하기 좋습니다.
      • 느린 속도
        • 서버가 DB 정보를 논리적인 형식으로 변환해야 하기 때문에 물리적 백업보다 느립니다.
      • 서버 중지 불필요
        • 서버는 실행 중인 상태여야 가능하지만, 잠금할 필요는 없습니다.
        • 운영 중인 서비스에 큰 영향 없이 백업을 진행할 수 있습니다.
      • mysqldump이나 INTO OUTFILE을 통해 백업할 수 있습니다.

온라인 백업과 오프라인 백업

  • 온라인 백업(Online Backup, Hot Backup)
    • 개념
      • 서버가 실행 중인 상태에서 백업을 진행하는 방식입니다.
    • 특징
      • 운영 중인 서비스나 다른 클라이언트는 데이터를 읽을 수 있습니다.
      • 적절한 잠금 필요: 데이터 백업과 복구시에 데이터의 무결성을 위해, 적절한 잠금 처리가 필요합니다.
  • 오프라인 백업(Offline Backup, Cold Backup)
    • 개념
      • 서버가 중지된 상태에서 백업을 진행하는 방식입니다.
      • 운영서버가 아닌 복제(Replica)서버를 오프라인으로 전환하여 백업하는 방식도 있습니다.
    • 특징
      • 오프라인이기 때문에, 모든 서비스가 중지됩니다.
      • 간단한 백업 절차: 서버가 중지되어 데이터 무결성이 지켜집니다.
  • Warm Backup
    • 개념
      • 온라인과 오프라인 중간의 개념을 의미합니다.
      • 서버는 실행 중이지만, 데이터 수정이 불가능한 상태에서 백업하는 방식
    • 특징
      • 데이터는 읽을 수 있지만, 수정할 수 없는 상태로 백업하는 것을 의미 합니다.

로컬 백업과 원격 백업

  • 로컬 백업(Local Backup)
    • 개념
      • 백업하는 서버와 백업의 대상 서버가 동일한 호스트에서 백업하는 방식입니다.
      • 백업 수행 서버 = 백업 대상 서버
    • 특징
      • 속도와 안정성: 동일한 서버에서 수행되어 빠르고 안정적입니다.
      • 물리적 백업: 물리적 백업시, 주로 로컬 백업 방식을 이용합니다.
  • 원격 백업(Remote Backup)
    • 개념
      • 백업하는 서버와 백업의 대상 서버가 다른 호스트에서 백업하는 방식입니다.
      • 백업 수행 서버 != 백업 대상 서버, 백업 수행 서버와 백업 대상 서버는 네트워크를 통해 통신하며 백업하는 방식힙니다.
    • 특징
      • 물리적 백업: 물리적 백업시, 백업 파일의 목적지는 원격지로 설정(scp, rsync 등을 이용)할 수 있습니다.

도구에 따른 비교

  • mysqldump
    • 로컬과 원격 관계없이 사용할 수 있습니다.
    • 저장 위치
      • SQL 형식: 클라이언트(명령어를 실행한 곳)에 저장됩니다.
      • --tab옵션 사용시(CSV 파일형식 등): 서버(명령어를 수행하는 곳)에 저장됩니다.
  • SELECT … INTO OUTFILE
    • 로컬과 원격 관계없이 사용할 수 있습니다.
    • 저장 위치: 항상 서버측(명령어를 수행하는 곳)에 저장됩니다.
  • 물리적 백업
    • 주로 로컬 백업 방식을 이용합니다.
    • 백업 파일의 목적지를 원격지로 설정(scp, rsync 등을 이용)할 수 있습니다.

mysqldump

  • 기본 사용
    • SQL 형식으로 출력되며, 표준출력에 보여집니다.
    • > 또는 >>연산자를 이용해, 파일로 저장합니다.
  • --tab 옵션 사용
    • 각 테이블에 대해 2개의 파일이 하나의 디렉토리에 생성됩니다.
      • 데이터 파일:데이터의 내용이 csv 와 같은 형식(tab을 구분자로 한 형식)의 텍스트 파일
      • 테이블 구조: 테이블 구조를 정의하는 SQL파일

스냅샷(Snapshot) 백업

  • 개념
    • 파일 시스템 상태를 그대로 캡처하여 보관하는 방식입니다.
    • 파일 시스템의 상태를 논리적으로 복사하는 방식(실제 파일 데이터를 전체 복사하는 것이 아님)입니다.
  • 특징
    • 일부 파일 시스템(LVM, ZFS, veritas Volume Manager)에서 지원하는 방식으로, DB에서 지원하는 방식이 아닙니다.
      • 따라서 DB에서 직접 복구에 사용되지 않습니다.
    • 복구시 활용
      • 스냅샷을 통해 파일 시스템 자체를 특정 시점으로 롤백합니다.
      • 스냅샷 파일을 별도의 디렉토리에 마운트해, 스냅샷 내의 데이터를 복사합니다.

전체 백업과 증분 백업

  • 전체 백업(Full Backup)
    • 개념
      • 전체 데이터를 특정 시점에 1번 백업하는 방식입니다.
    • 특징
      • 완전한 복구 가능
        • 특정 시점의 상태를 완전히 복원할 수 있습니다.
        • 백업 시점 이후 내용이 변경되었다면, 최신 상태가 아닐 수 있습니다.
      • 백업 파일 크기: 서버에 존재하는 모든 데이터를 백업하기 때문에 큽니다.
      • 백업 속도: 백업 파일의 크기가 커서 느립니다.
      • mysqldump, mysqlbackup 등을 이용해 전체 데이터를 백업합니다.
  • 증분 백업(Point-in-Time Backup)
    • 개념
      • 변경된 데이터만 추가로 백업하는 방식입니다.
      • 전체 백업과 조합하여 사용합니다.
        • 전체 백업 이후의 변경된 데이터를 백업합니다.
    • 특징
      • 복구
        • 전체 백업을 먼저 복원 -> 변경사항을 순차적용
      • 백업 파일 크기: 변경된 데이터만 백업하므로 백업 파일의 크기가 작습니다.
      • 백업 속도: 백업 파일 크기가 작아 빠릅니다.
      • Binary Log를 이용하여 변경 사항을 기록합니다.
        • Binary Log를 활성화하면 데이터 변경 사항이 로그 파일에 기록합니다.
        • 특정 시점까지만 복구할 수 있습니다.

백업 스케줄링, 압축, 암호화

백업 스케줄링, 압축, 암호화는 백업 절차를 자동화 하는데 유용합니다.

DB에서는 직접 제공하지 않아, 다른 솔루션을 이용해야합니다.

  • 예시
    • 스케줄링: linux의 crontab, windows scheduler 등을 이용해 백업 주기 설정
    • 압축: gzip, tar, zip을 이용해 백업 파일 압축
    • 암호화: openssl 등을 이용해 백업 파일 암호화

백업 전략

다양한 백업 방식을 아는 것보다 중요한건, 이를 이용해 실무에서 백업을 하고 문제상황이 생겼을 때 백업을 이용해 복구하는 것입니다.
그러기 위해서는 백업 정책을 정의하는 것이고, 백업 정책에서 중요한 것은 정기적인 백업이 이루어져야 하며, 백업 후 복구 가능성을 항상 점검해야 합니다.

mysql에서 제공하는 예시를 통해 어떻게 정기적인 백업을 설정해야하고,이를 복구시에 이용할지에 대해 알아봅시다.

전체 백업 이용하기

물리적 백업을 할 수도 있고, 논리적인 백업을 할 수도 있겠지만, 여기서는 mysqldump를 이용한 논리적 백업을 이용합니다.

가장 부하가 적은 시간대에 전체 백업을 수행합니다.

일요일 오후 1시에 전체 백업을 수행, 백업할 테이블은 InnoDB라고 가정

$> mysqldump --all-databases --source-data --single-transaction > backup_sunday_1_PM.sql

-> 현재 시점에 전체 데이터를 백업해 파일(backup_sunday_1_PM.sql)을 만들라는 의미

  • --all-databases: 모든 database를 백업합니다.
  • --source-data: 백업 시점의 Binary Log파일의 이름과 위치를 덤프 파일에 기록합니다.
  • --single-transaction: InnoDB 테이블에 대한 일관된 읽기 제공하여 데이터 무결성을 보장합니다.

일관된 읽기

  • 다른 클라이언트가 데이터 테이블에 변경한 사항은 mysqldump 프로세스에서 볼 수 없도록 함
  • 만약, 백업 작업에 비트랜잭션 테이블이 포함된 경우 일관성을 위해 백업 중에 변경되지 않아야 합니다.
    • For example, 백업 중에 MySQL 계정에 대한 관리 변경

이후에 주기적으로 백업한다면, (이전 백업파일은 삭제하고, 생략가능) 다시 전체 백업을 진행합니다.

복원시에는 아래와 같은 명령어를 이용해 복원할 수 있습니다.

$> mysql < backup_sunday_1_PM.sql

증분 백업(변경에 대한 백업)을 같이 이용하기

만약 여기서, 일부 백업도 같이 이용한다면 어떤 방식일까요?

$> mysqldump --single-transaction --flush-logs --source-data=2 --all-databases > backup_sunday_1_PM.sql

-> 현재 시점에 전체 데이터를 백업해 파일(backup_sunday_1_PM.sql)을 만들고, 이후의 변경 데이터는 Binary Log에 저장하도록 설정하는 의미

  • --flush-logs: 백업 시 로그를 플러시하여 새로운 Binary Log 파일을 시작합니다.

  • --source-data=2: 현재 Binary Log 파일과 포지션 정보를 백업 파일에 기록합니다.

      -- Position to start replication or point-in-time recovery from
  -- CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='gbichot2-bin.000007',SOURCE_LOG_POS=4;
    • 1번째 줄: 덤프 파일(=backup_sunday_1_PM.sql)에는 “gbichot2-bin.000007” Binary Log 파일이나 그 이상에 기록된 변경 사항 이전에 작성된 모든 변경 사항이 포함되어 있습니다.
    • 백업 후 기록된 모든 데이터 변경 사항은 덤프 파일(=backup_sunday_1_PM.sql)에는 없지만, “gbichot2-bin.000007” Binary Log 파일 이상에는 존재합니다.

이후에 주기적으로 백업을 수행한다면, mysqladmin flush-logs 명령어를 이용해 새 Binary Log에 이후 변경 데이터를 저장하도록 합니다.

순서 정리

  1. 1일 오후 1시: mysqldump를 이용해 전체 데이터 백업 + 이후 변경 데이터는 Binary Log에 저장
    • 전체 데이터: backup_sunday_1_PM.sql에 저장
    • 변경 데이터: gbichot2-bin.000007에 저장
  2. 8일 오후 1시: mysqladmin flush-logs로 새로운 변경 데이터 저장
    • 변경 데이터: gbichot2-bin.000008에 저장
    • 이전 데이터가 삭제되지 않고, gbichot2-bin.000007에 저장된 변경데이터를 gbichot2-bin.000008에 저장
  3. 15일 오후 1시: mysqladmin flush-logs로 새로운 변경 데이터 저장
    • 변경 데이터: gbichot2-bin.000009에 저장
    • 이전 데이터가 삭제되지 않고, gbichot2-bin.000008에 저장된 변경데이터를 gbichot2-bin.000009에 저장

복원시에는 전체 백업 데이터를 이용해 복원한 후, Binary Log파일을 순서대로 적용해 복원합니다.

  • 전체 데이터 복원

      $> mysql < backup_sunday_1_PM.sql

  • 변경 데이터 복원

      $> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

주의

백업 데이터가 누적되면 용량이 커질 수 있으니, 적절한 주기로 백업데이터를 삭제하거나 압축하여 관리해야합니다.

고려사항

  • 클라이언트가 DB에 접근하는 주요 시간: 사용량이 적은 기간이 예측된다면, 백업을 예약하는 것이 좋습니다.
  • 변경 사항이 발생하는 주기: 잦은 변경사항이 있다면, 전체 백업과 증분 백업을 고려하세요.
  • DB의 변경 범위: DB 전체가 변경되는지, 일부분만 변경되는지에 따라 부분 백업이나 전체 백업을 부분 백업을 진행하세요.
  • 백업을 위한 디스크 공간
  • 백업을 유지할 기간: 비즈니스 로직에서 유지되어야하는 기간을 고려하며 백업 일정을 설정하고, 백업 데이터를 삭제시에 삭제해도 유지되어야하는 기간에 대해서는 관계가 없는지 확인해야합니다.
  • 백업 테스트: 백업을 테스트 하기 전까지는 제대로 백업이 되는지 알 수 없고, 복원에 사용될 수 있을지 알 수 없습니다.

참고 자료