일일 백업으로 충분한가요?

백업과 복제(replication)는 두 가지 다른 개념입니다.

백업은 특정 시점의 데이터 스냅샷을 제공합니다. 즉, 복구 포인트를 제공합니다.

복제는 모든 작업을 다른 시스템으로 분산시켜 데이터를 한 곳 이상에서 보유할 수 있도록 하는 것입니다. 삭제 작업도 복제됩니다.

정말 장애 허용(fault tolerance)을 원한다면, 이 두 가지를 모두 갖추어야 합니다. (그리고 더 많은 것이 필요할 수 있습니다…)

따라서 복제는 현재 데이터를 여러 위치에 두는 문제만 해결합니다. 백업은 시스템을 특정 시점으로 복구하는 방법을 제공합니다.

Discourse는 저장을 위해 두 가지 메커니즘을 사용합니다:

  1. 첨부 파일 제외 모든 데이터를 위한 PostgreSQL 데이터베이스
  2. 로컬 시스템 또는 S3에 저장되는 첨부 파일

PostgreSQL 데이터베이스에 저장된 데이터를 백업하고/또는 복제하려면, 이를 수행하는 방법에 대한 PostgreSQL 문서를 확인하세요. 백업에 관하여복제.

첨부 파일은 조금 더 까다롭습니다. S3에 저장하는 경우 S3 백업을 사용할 수 있습니다. 로컬에 저장된 파일의 경우 다양한 로컬 시스템 옵션을 사용할 수 있습니다.

데이터 양에 따라 전체 백업을 생성하는 것은 무거운 작업입니다. 따라서 이를 더 자주 수행하기는 어렵습니다. Discourse의 표준 백업 절차는 전체 백업을 생성하는 것입니다. 데이터 손실 위험을 줄이고 싶다면 다른 옵션을 찾아야 합니다.

한 가지 옵션은 호스팅 서비스에서 제공될 수 있습니다: 볼륨 스냅샷. 이는 볼륨에 저장된 데이터의 “즉시” 복사본을 만드는 방법을 제공합니다. 이를 통해 볼륨을 해당 시점으로 복구할 수 있습니다. 사용 중인 파일 시스템에 따라 OS 내에서 볼륨 스냅샷이 제공될 수도 있습니다. (예: btrfs는 이를 지원합니다.)

이 외에도 PostgreSQL 문서에는 데이터베이스의 더 연속적인 백업을 생성하여 데이터베이스의 뛰어난 시점 복구(point-in-time-recovery)를 가능하게 하는 내용이 포함되어 있습니다. (백업을 오프사이트로 전송하는 것을 잊지 마세요.) 이는 전체 백업보다 훨씬 빠릅니다.

더 세밀한 첨부 파일 백업을 위해 전체+차등 백업을 관리할 수 있는 다양한 백업 도구를 사용할 수 있습니다. 예를 들어 duplicity를 사용할 수 있습니다. 또는 rsync(삭제 없이)를 사용할 수도 있습니다. 스냅샷 사이에서는 여전히 파일을 잃을 수 있습니다. 삭제 없이 S3를 사용하는 것이 더 안전할 수 있으며, 파일이 이미 다른 시스템에 있기 때문입니다.

결론적으로, Discourse의 표준 백업 메커니즘은 더 빈번한 백업 일정에 적합하지 않습니다. 더 많은 백업을 원한다면, 표준 PostgreSQL 백업/복제 기능, S3, 볼륨 스냅샷 등의 조합을 사용하세요.

제 사이트에서는 정기적인 백업에 Discourse의 백업 시스템을 사용하지 않습니다. 여전히 일일 백업을 유지하지만, pg_dumps와 duplicity 설정(backupninja를 통해 조정)의 조합을 사용합니다.