EC2-PostgreSQL 데이터를 올바르게 백업하는 방법?

설정은 다음과 같습니다. 3 개의 추가 볼륨이있는 1 개의 작은 Amazon Linux (EBS 지원) ​​EC2 인스턴스. 이것은 웹 서버 및 데이터베이스 서버입니다. 하나는 코드, 하나는 PostgreSQL (8.4) 데이터 디렉토리, 그리고 하나는 PostgreSQL의 WAL 파일을 저장하는 볼륨입니다.

(1) WAL 파일이있는 볼륨에는 데이터 디렉토리의 기본 백업이 있으며 pg_start_backup ()을 수행 한 후에 복사됩니다. 그런 다음 PostgreSQL (WAL 파일)의 연속 아카이브 출력을 저장합니다. 이 볼륨의 스냅 샷을 만들려면 동기화를 실행하고 파일 시스템을 정지시키는 데 문제가 있습니까 (XFS 인 경우 xfs_freeze 또는 EXT4 인 경우 dmsetup 사용)? 아니면 라이브 스냅 샷을 찍을 수 있습니까? WAL 파일은 분당 1 개의 속도로 배송됩니다. 단일 WAL 파일을 복사하는 동안 스냅 샷이 시작되어 데이터가 손상 될 수 있습니까?

(2) 라이브 PostgreSQL 데이터 디렉토리를 포함하는 볼륨도 매일 측정하기 위해 백업됩니다. 이 볼륨의 스냅 샷을 수행하기 전에 pg_dump를 실행하면 결과 SQL 파일이 데이터 디렉토리에 유지됩니다. 실제 데이터베이스 데이터의 일관성을 유지하기 위해 예방 조치를 취해야 할 점이 있습니까? 라이브 스냅 샷을 작성하면 (a) 구성 파일 (postgresql.conf, pg_hba.conf, pg_ident.conf)을 백업하고 (b) SQL 덤프 파일을 올바르게 백업한다고 가정하는 것이 옳습니까? 이 두 가지를 백업하는 것이 바로 SQL 덤프 파일과 구성 파일입니다. DB가 크지 않기 때문에 데이터 파일 이이 스냅 샷을 팽창시킬 것이라는 사실은 신경 쓰지 않습니다. 이 경우 라이브 스냅 샷을 만들 수 있습니다. 맞습니까?

(2a) 루트 볼륨에 데이터 디렉토리를 유지하고 SQL 덤프 파일과 구성 파일을 다른 볼륨에 복사하고 복사가 완료되면 해당 볼륨을 스냅 샷하는 백업 스크립트를 보유하는 것이 더 좋을까요?

(3) 코드가있는 볼륨은 파일 시스템을 동기화하고 고정시키는 데 어떤 점이 있습니까? 아니면 라이브 스냅 샷 만 찍을 수 있습니까? 이 데이터는 상당히 "정적"이어야합니다.

(4) 이것이 확실한 백업 구성표입니까? 루트 볼륨은 머신 이미지를 설정하고 구성한 후에 만 ​​유지하기 때문에 정기적으로 백업되지 않습니다.

감사

훌륭한 매뉴얼을 참조하십시오 . 내 조언이 어쨌든 '와 상충된다면'맞습니다.

1. 복사 도구 fsync ()가 작성하는 각 WAL 파일과 다음 파일을 복사하기 전에 파일이있는 디렉토리가 아니라면 동기화는 나쁘지 않습니다. 불완전한 마지막 WAL 파일은별로 중요하지 않습니다. 최악의 경우, 그냥 삭제하면됩니다. 더 체크섬이 이루어지지가 비록 당신이 그래서 - 대학원은 일반적으로 불완전한 WAL에 질식 할 수정말 운이 좋지 않고 순전히 우연히 실제 WAL 레코드처럼 보이는 가비지 데이터를 적용하도록하십시오. 귀하의 입장에서 RAM에 기록되지 않은 더티 버퍼가 디스크의 파일 시스템 이미지에 도달하도록 스냅 샷 전에 볼륨을 동기화하고 있습니다. 동결은 지저분하지만 치명적이지 않은 부분적으로 작성된 WAL을 피하는 데 도움이되므로 끔찍한 아이디어는 아니지만 중요하지는 않습니다. 가장 중요한 것은 복구 시점까지 손상되지 않은 타임 라인을 유지하는 것입니다. 개인적으로 WAL을 임시 파일 이름으로 작성하고 완전히 복사 한 후에 만 ​​최종 이름으로 이름을 바꿉니다. 이렇게하면 얼지 않아도됩니다.

2. 정확합니다. 라이브 스냅 샷은 write-through 캐싱을 사용하는 라이브 시스템에서 플러그 풀 테스트를 수행하는 것과 같습니다. 플러그 풀 후와 마찬가지로 라이브 스냅 샷에서 복원 할 때 데이터베이스가 제대로 복구됩니다. 스냅 샷에서 복원 테스트를 자동화하는 것이 좋습니다. (참고 : 테스트를 복원 스냅 샷입니다 하지 가능 디스크, RAID 컨트롤러 등 쓰기 캐싱을 고려하지 않기 때문에 플러그 풀 테스트를위한 완전한 대체). 구성 파일 및 덤프뿐만 아니라 데이터베이스 자체도 스냅 샷 후에 양호해야합니다. 모든 덤프 데이터 등이 실제로 디스크에 닿도록 스냅 샷 전에 볼륨을 동기화하십시오.
   
   2a. 디스크 공간을 절약 할 수 있습니다. 그렇지 않으면 약간의 차이가 있습니다. 라이브 데이터베이스의 모든 변경 사항없이 스냅 샷을 훨씬 더 오래 유지할 수 있습니다.

3. 왜 코드 볼륨을 스냅 샷합니까? 평범한 파일 레벨 사본은 괜찮을 것입니다. 확실히 라이브 스냅 샷이어야합니다.

4. 이것은 확실한 백업 구성표가 아닙니다. 하나의 중요한 영역에서 실패합니다. 복원 테스트 및 검증이 수행되지 않습니다. 항상 정기적으로 백업 을 테스트하여 실제로 복원 할 수 있는지 확인해야합니다.

   개인적으로 WAL 배송을 사용하거나 데이터베이스 덤프를 다른 호스트 , 바람직하게 는 Amazon EC2에 있지 않거나 적어도 다른 지역에 보내는 것이 좋습니다 . 이 호스트는 자동 복원 테스트를 수행하고 결과를 보고서로 보내야하며 수동으로 확인해야합니다.

   스냅 샷 (덤프 포함)이 S3에 있고 안전 할지라도 긴급하게 필요할 때 액세스 할 수있는 것은 아닙니다. Amazon의 내구성 주장은 안심이되지만 S3 서비스가 제대로 중단되지 않은 동안에도 데이터는 안전하고 완벽하게 액세스 할 수 없습니다.