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

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

기존 Mastodon 백업 방식은 정기적으로 pg_dumps를 실행하고 scp로 다른 머신에 복사하는 것이었습니다. 그 머신 역시 로컬 NAS에 백업되고 있었기 때문에 이 정도면 충분히 괜찮았습니다. 다만 오래된 백업을 반정기적으로 수동으로 정리해야 했고, 인스턴스를 운영한 지 꽤 된 만큼 이제는 더 나은 방식을 갖추면 좋겠다고 생각했습니다.

최근에는 Cloudflare R2를 활용하도록 백업을 조금 개선했습니다.

R2

R2에 인스턴스의 모든 에셋을 저장하고 있습니다. 스토리지는 S3보다 훨씬 저렴하고, 송신 요금도 없습니다! S3는 예상치 못한 대역폭 요금이 걱정됩니다.

2023년 5월 기준으로 R2에서도 수명 주기 정책을 지원합니다.

설정

먼저 새로운 R2 버킷을 만듭니다. 백업 저장용으로 사용할 버킷입니다. 공개 접근이 차단되어 있는지 꼭 확인하세요!

다음으로 로컬에서 aws cli를 설정합니다. 버킷 범위로 제한되고 객체 읽기/쓰기 권한을 가지며 Mastodon 서버의 IP 주소에서만 접근 가능하도록 API 토큰을 만들었습니다. aws configure를 실행한 뒤 새로 발급받은 계정 ID와 시크릿을 붙여 넣습니다.

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

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

이제 수명 주기 정책을 설정할 수 있습니다.

버킷 설정으로 이동한 뒤 수명 주기 정책을 선택하세요.

일일 백업은 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를 선택했습니다. 압축률은 최고 수준이지만 속도가 매우 느리다는 단점이 있습니다. 제 Mastodon 인스턴스는 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

중복되는 작업이 일부 있지만 크게 문제되지는 않습니다. 백업이 완료되면 Telegram으로 알림을 받도록 해 두었기 때문에, 제가 깨어 있는 시간대에 실행되도록 일정을 잡았습니다.

개선할 점

향후에는 wal-g를 사용하도록 바꿀 수도 있습니다. 지금 규모에서는 다소 과하다고 생각하며, pg_dump를 이용한 백업/복원 과정이 매우 간단합니다. DB 크기가 너무 커지거나 특정 시점 복구가 필요해지면 다시 검토할 예정입니다.