지난 한 달 동안 우리는 다양한 시나리오와 도커 컨테이너에서 수많은 마이그레이션 테스트를 수행했습니다. 또한, 저는 한 서버에서 다른 서버로 디스코र्स(DB)를 복원하는 작업도 추가로 여러 번 진행했습니다.
광범위한 복구 테스트를 바탕으로, 디스코र्स의 복원 과정은 훌륭하며 커맨드 라인에서 모든 상황에서 완벽하게 작동했습니다.
예를 들어, 우리는 이 작업을 위해 매우 단순한 스크립트를 사용하는데, 저는 이 스크립트를 /shared/neo/bin 디렉터리에 저장해 두었습니다:
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community-2020-03-27-033157-v20200320193612.tar.gz
echo "discourse disable_restore"
discourse disable_restore
물론 이 작은 bash 스크립트는 필수적이거나 우아하지는 않습니다. 하지만 바쁠 때 최신 백업 파일을 스크립트에 그대로 붙여넣고 복원을 수행하고 싶을 때, 이처럼 “쉽고 빠르게” 만들어주는 작은 스크립트는 정말 큰 도움이 됩니다.
저는 항상 커맨드 라인에서(앱 환경이든, 도커 환경이든) 복원을 수행하며, 수많은 테스트 시나리오를 거쳤음에도 디스코र्स의 복원 과정은 한 번도 실패한 적이 없습니다. 새 디스코르 도커 설치 환경을 생성하고 커맨드 라인에서 복원하면 “뽀그” 하고 끝납니다.
도커 이전의 "공룡 시대"와 비교해 보면, 도커 환경에서 디스코르 복원 과정의 탁월함 덕분에 복구 프로세스가 훨씬 더 쉽고 빠르게 진행됩니다.
예를 들어, 우리는 디스코르 백업 파일을 오프사이트(프로덕션 디스코르 인스턴스가 있는 서버와 다른 서버)에도 복사해 두고 있습니다. 만약 그 프로덕션 서버나 데이터 센터가 재앙으로 인해 "폭발"한다면, 원하는 어떤 서버에서든 디스코르 인스턴스를 처음부터 다시 구축하고 쉽게 복원할 수 있습니다(물론 DNS TTL을 짧게 유지해야 하지만, 이는 별개의 주제입니다).
이처럼 잘 설계되고 훌륭하게 구성된 백업 및 복구 프로세스를 만들어 주신 디스코르 팀에 축하의 말씀을 드립니다!
결함 없이, 매번 훌륭하게 작동합니다.