Skip to main content
Overleaf를 발전시키면서 때때로 데이터베이스의 데이터 스키마를 변경해야 하며, 이 과정을 자동화하기 위해 마이그레이션 스크립트를 사용합니다. 이 스크립트는 세계에서 가장 큰 Overleaf 인스턴스인 overleaf.com에서 먼저 실행되므로 대부분의 상황은 이미 겪어 보았지만, 사용자의 데이터에 대해서는 어떠한 보장도 하지 않습니다. 인스턴스를 업그레이드하기 전에 반드시 데이터의 일관된 백업을 만들어 두세요.
새 Docker 이미지로 업그레이드하면 아직 실행되지 않은 마이그레이션이 자동으로 실행됩니다. 데이터셋 크기에 따라 시간이 걸릴 수 있으며, 로그를 tail하면 진행 상황을 확인할 수 있습니다. 자세한 내용은 로깅 문서를 참고하세요.

데이터 저장소

Overleaf Community Edition과 Server Pro는 데이터를 세 곳에 나누어 저장합니다.
  • MongoDB 데이터베이스: 사용자 및 프로젝트 데이터가 저장되는 곳입니다.
  • Redis: 처리 중인 데이터를 위한 고성능 캐시 역할을 하며, 주로 프로젝트 편집 및 협업과 관련된 정보를 저장합니다.
  • Overleaf 파일 시스템: 편집할 수 없는 프로젝트 파일(이미지 포함)을 저장하며, 프로젝트 컴파일 중에는 임시 디스크 캐시 역할도 합니다.
인스턴스를 설정한 시기에 따라 ~/sharelatex_data 또는 ~/overleaf_data일 수 있습니다.
프로젝트 파일과 전체 프로젝트 기록 데이터에 대해서는 S3 호환 스토리지 백엔드도 지원합니다.
디스크의 폴더 구조에 대한 자세한 내용은 ‘폴더 상세 설명’을 참고하세요.

일관된 백업 수행

일관된 백업을 만들 때 포함해야 하는 저장소는 세 가지입니다.
  • MongoDB
  • Redis
  • Overleaf 파일 시스템 데이터
일관된 백업을 만들려면 백업 과정이 진행되는 동안 사용자가 새 데이터를 생성하지 못하도록 하는 것이 필수입니다. 따라서 사용자가 인스턴스에 접근하거나 프로젝트를 편집할 수 없는 유지 관리 시간대를 계획할 것을 권장합니다. 백업 과정을 시작하기 전에 인스턴스를 오프라인으로 전환해야 합니다. Server Pro 3.5.0부터는 종료 과정에서 사이트 닫기와 사용자 연결 해제가 자동으로 처리됩니다. 인스턴스를 종료하려면 Toolkit 배포를 사용하는 경우 bin/docker-compose stop sharelatex를, Docker Compose를 사용하는 경우 docker compose stop sharelatex를 실행해야 합니다. sharelatex 컨테이너가 중지되면 백업 과정을 시작할 수 있습니다. 백업 과정이 성공적으로 완료되면 sharelatex 컨테이너를 시작해야 합니다. 이를 위해 Toolkit 배포를 사용하는 경우 bin/docker-compose start sharelatex를, Docker Compose를 사용하는 경우 docker compose start sharelatex를 실행합니다.
  • 백업은 Overleaf 인스턴스가 실행 중인 서버와 별도의 서버에, 가능하면 완전히 다른 위치에 저장해야 합니다.
  • 데이터베이스를 여러 MongoDB 인스턴스로 복제하면 어느 정도 중복성을 확보할 수 있지만, 데이터 손상으로부터 보호해 주지는 않습니다.
  • 백업을 테스트하는 것이 백업이 완전하고 제대로 동작하는지 확인하는 가장 좋은 방법입니다.

MongoDB

MongoDB에는 데이터베이스에 저장된 사용자 및 프로젝트 데이터의 백업을 만드는 데 사용할 수 있는 mongodump라는 명령줄 도구가 포함되어 있습니다.

Overleaf 파일 시스템 데이터

Toolkit 배포의 경우 편집할 수 없는 파일이 저장되는 경로는 config/overleaf.rc의 OVERLEAF_DATA_PATH 환경 변수로 지정되지만, 인스턴스를 생성한 시기에 따라 data/sharelatex일 수도 있습니다. 완전한 백업을 만들려면 rsync 같은 도구를 사용하여 이 디렉터리를 재귀적으로 복사해야 합니다.

Redis

Redis는 사용자 세션과, MongoDB로 플러시되기 전의 대기 중인 문서 업데이트를 저장합니다. Redis 영속성에는 AOF(Append Only File) 영속성 구성을 권장합니다. Toolkit 사용자의 경우 새로 설치하면 기본적으로 AOF 영속성이 활성화되어 있습니다. 기존 사용자는 AOF 활성화에 대한 자세한 내용을 여기에서 확인할 수 있습니다. AOF 영속성과 함께 RDB 스냅샷을 계속 사용하기로 했다면 RDB 파일을 안전한 위치에 복사하여 백업으로 보관할 수 있습니다.

서버 간 데이터 마이그레이션

가장 좋은 경우는 새 인스턴스에 아직 중요한 데이터가 없는 것입니다. 인스턴스 간 데이터를 병합하는 절차는 제공하지 않습니다. 새 인스턴스에 아직 데이터가 없다고 가정하면 다음 단계를 따를 수 있습니다. 전체적으로는 mongo, redis, overleaf 볼륨의 tar 아카이브를 만들어 새 서버로 복사한 다음 그곳에서 다시 압축을 풉니다.

Toolkit

Docker Compose

docker-compose.yml 파일에 따라 mongo, redis, overleaf 볼륨의 경로를 조정해야 할 수 있습니다.
root 사용자로(또는 sudo로) 실행하면 tar가 파일의 소유자/그룹과 권한을 유지하며, 이는 백업을 복원할 때 매우 중요합니다.

폴더 상세 설명

다음 폴더에는 추가 표시가 붙어 있습니다.
  • (b) 백업에 포함하며, 일관성을 보장하려면 인스턴스를 중지한 상태에서 하는 것이 가장 좋습니다
  • (d) 삭제할 수 있습니다
  • (e) 임시 파일이며, 인스턴스가 중지된 상태에서 삭제할 수 있습니다
  1. ~/mongo_data (b)
    • mongodb 데이터 디렉터리
  2. ~/redis_data (b)
    • redis db 데이터 디렉터리
  3. ~/overleaf_data
    1. bin
      1. synctex (d)
        • 최신 릴리스에서는 사용되지 않으며, 이전에는 사용자 지정 synctex 바이너리가 사용되었습니다(synctex는 .tex 파일과 pdf 간의 소스 매핑에 사용됩니다)
    2. data
      1. cache (e)
        • 컴파일용 바이너리 파일 캐시
      2. compiles (e)
        • LaTeX 컴파일이 이루어지는 곳
      3. db.sqlite (d)
        • 최신 릴리스에서는 사용되지 않으며, 이전에는 clsi 캐시 세부 정보를 저장했습니다(현재는 간단한 인메모리 맵으로 옮겨졌거나 디스크를 스캔합니다)
      4. db.sqlite-wal (d)
        • 최신 릴리스에서는 사용되지 않습니다. db.sqlite를 참고하세요
      5. output (e)
        • 클라이언트에 제공하기 위한 LaTeX 컴파일 출력 저장소
      6. template_files (b)
        • 템플릿 시스템의 이미지 미리보기(Server Pro 전용)
      7. user_files (b)
        • 프로젝트의 바이너리 파일
      8. history (b)
        • 전체 프로젝트 기록 파일
    3. tmp
      1. dumpFolder (e)
        • zip 파일 처리 시 생성되는 임시 파일
      2. uploads (e)
        • 파일 업로드 버퍼링(바이너리 파일/zip에서 새 프로젝트 업로드)
      3. projectHistories (e)
        • 전체 프로젝트 기록 마이그레이션용 임시 파일
마지막 수정일 2026년 10월 5일