저는 https://bikers.social의 관리자입니다. 바이커들을 위한 마스토돈 인스턴스죠 🏍️

Postgres는 인스턴스 백업에서 가장 중요한 부분입니다. DB를 잃으면 끝장이에요. 제 시크릿들도 함께 백업해 두고 있습니다.

예전 마스토돈 백업 정책은 정기적인 pg_dumps와 다른 머신으로의 scp로 이루어져 있었습니다. 그 머신 또한 로컬 NAS에 백업되고 있었기 때문에 이 정도면 충분히 괜찮았습니다. 다만 오래된 백업을 반정기적으로 수동으로 정리해야 했고, 인스턴스를 운영한 지 꽤 된 지금은 더 나은 방법이 있으면 좋겠다고 생각했습니다.

최근에 이를 조금 손봐서 Cloudflare R2를 사용하도록 바꿨습니다.

R2

인스턴스의 모든 에셋을 R2에 저장하고 있습니다. S3보다 스토리지가 훨씬 저렴하고, 송신 요금도 없습니다! S3를 쓰면 예상치 못한 대역폭 요금이 청구될까 봐 좀 걱정될 것 같습니다.

2023년 5월 기준으로 R2는 라이프사이클 정책도 지원합니다

설정

먼저 새로운 R2 버킷을 만드세요. 이 버킷은 저장소로 사용될 겁니다. 공개 접근이 불가능하도록 설정하세요!

다음으로 로컬 aws cli를 설정합니다. 저는 해당 버킷에만 적용되고 오브젝트 읽기/쓰기 권한을 가지며, 마스토돈 서버의 IP 주소로만 제한된 API 토큰을 만들었습니다. aws configure를 실행하고 새로 발급받은 계정 ID와 시크릿을 붙여 넣으세요.

AWS cli는 기본적으로 사용하려는 엔드포인트가 Amazon이라고 가정합니다. 최신 버전의 CLI는 config에서 설정할 수 있지만, 패키지 저장소가 최신이 아닐 가능성이 높습니다. 이후의 모든 명령어에서는 다음과 같이 설정했습니다

alias aws='aws --endpoint-url https://<account ID>.r2.cloudflarestorage.com'

그런 다음 라이프사이클 정책을 설정할 수 있습니다.

버킷 설정으로 이동한 다음 lifecycle policy를 선택하세요

일일 백업은 1주일, 주간 백업은 6주, 월간 백업은 6개월간 유지하도록 라이프사이클 규칙을 설정했습니다.

스크립트

제 백업 스크립트는 아주 간단합니다. 실행하면 당일 날짜의 파일을 만들고, 지정된 프리픽스와 함께 r2에 업로드합니다.

#! /bin/bash

prefix=${1:-daily}
date=$(date '+%Y-%m-%d')

pg_dump -Fc -Z 0 -U mastodon mastodon_production | xz -T4 > $date.sql.xz

aws --endpoint-url https://<account ID>.r2.cloudflarestorage.com s3 cp ./$date.sql.xz s3://<bucket name>/$prefix/$date.sql.xz

프리픽스를 지정하지 않으면 일일 백업으로 간주합니다.

백업에는 xz를 선택했습니다. 최고의 압축률 중 하나를 제공하지만, 대신 속도가 매우 느립니다. 제 마스토돈 인스턴스는 Hetzner 박스를 쓰고 있고 트래픽이 그리 많지 않아서 사양이 꽤 오버스펙인 편입니다.

pg_dump -Fc -Z 0 - 커스텀 포맷을 사용하되, 압축은 xz로 할 것이므로 비활성화한 것입니다

xz -T4는 xz 압축을 사용하되 최대 4개의 스레드만 사용합니다. -T0로 시도해 보니 16개 스레드를 전부 풀로 써서 좀 과하다는 느낌이 들었습니다. 4개로도 충분히 빠르게 완료됩니다.

Crontab

다음 명령어로 수동 테스트를 한 뒤

./backup.sh daily
./backup.sh weekly
./backup.sh monthly

모든 파일이 정상적으로 생성된 것을 확인하고 crontab을 설정했습니다

0 12 * * * /home/mastodon/backup.sh daily
0 13 * * 0 /home/mastodon/backup.sh weekly
0 14 1 * * /home/mastodon/backup.sh monthly

약간의 중복 작업이 있지만 여기서는 크게 문제되지 않습니다. 백업이 완료되면 텔레그램으로 알림을 받도록 설정해 두었기 때문에, 제가 깨어 있는 시간대에 실행되도록 스케줄링했습니다.

개선 방향

향후에는 wal-g를 사용하도록 바꿀 수도 있습니다. 지금 상황에서는 꽤 과하다고 생각하고, pg_dump를 이용한 백업/복원 과정이 매우 간단하기도 합니다. 데이터베이스 크기가 너무 커지거나 특정 시점 복구가 필요해지면 그때 다시 고려해 볼 생각입니다.