Skip to main content
Overleaf の進化に伴い、データベース内のデータのスキーマを変更する必要が生じることがあり、その処理はマイグレーションスクリプトで自動化されています。これらのスクリプトは、世界最大の Overleaf インスタンスである overleaf.com で先に実行されているため、ほとんどの事態はすでに経験済みですが、お客様のデータについて保証するものではありません。インスタンスをアップグレードする前に、必ずデータの整合性のあるバックアップを作成してください。
新しい Docker イメージにアップグレードすると、まだ実行されていないマイグレーションが自動的に実行されます。データセットのサイズによっては時間がかかる場合があり、ログを tail することで進捗を確認できます。詳しくは Logging のドキュメントを参照してください。

データの保存先

Overleaf Community Edition と Server Pro は、データを 3 つの別々の場所に保存します。
  • MongoDB データベース: ユーザーとプロジェクトのデータが保存されます。
  • Redis: 処理中のデータのための高性能キャッシュとして機能し、主にプロジェクトの編集や共同作業に関する情報を保存します。
  • Overleaf ファイルシステム: 編集不可のプロジェクトファイル(画像を含む)を保存し、プロジェクトのコンパイル中の一時的なディスクキャッシュとしても機能します。
インスタンスをセットアップした時期によって、これは ~/sharelatex_data または ~/overleaf_data になります。
プロジェクトファイルと完全なプロジェクト履歴データについては、S3 互換のストレージバックエンドにも対応しています。
ディスク上のフォルダー構成について詳しくは、「フォルダーの詳細」を参照してください。

整合性のあるバックアップの実行

整合性のあるバックアップを取得する際には、次の 3 つのストアを含める必要があります。
  • 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 の永続化には、Append Only File(AOF)による永続化が推奨される設定です。 Toolkit ユーザーの場合、新規インストールではデフォルトで AOF 永続化が有効になっています。既存ユーザーは、AOF の有効化についてこちらで詳しく確認できます。 AOF 永続化と併せて RDB スナップショットも引き続き使用する場合は、RDB ファイルを安全な場所にコピーしてバックアップとすることができます。

サーバー間のデータ移行

新しいインスタンスには、まだ重要なデータがない状態が理想的です。インスタンス間でデータをマージする手順は用意されていません。 新しいインスタンスにまだデータがないと仮定して、次の手順に従うことができます。大まかには、mongo、redis、overleaf の各ボリュームの tarball を作成し、新しいサーバーにコピーして、そこで再び展開します。

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日