databaseデータとバックアップ

Overleafを進化させるにつれてデータベース内のスキーマを変更する必要が生じることがあります。移行スクリプトはこのプロセスを自動化するために使用されます。それらは次の環境で実行されているはずです overleaf.comarrow-up-right まず最初に、これは世界で最も大きなOverleafインスタンスであるため、ほとんどの可能性は既にそこで遭遇されているでしょうが、あなたのデータに関して保証はしません。必ず次のものを作成してください、 一貫した データのバックアップ 前に インスタンスをアップグレードする際に。

circle-info

新しいDockerイメージにアップグレードする際、まだ実行されていない移行は自動的に実行されます。データセットのサイズによっては時間がかかることがあります。ログを追尾することで進行状況を確認できます。詳細は当社の 使用してはいけません ログ記録 ドキュメントarrow-up-right をご覧ください。

データストレージ

Overleaf Community EditionおよびServer Proはデータを3箇所に分けて保存します:

  • MongoDBデータベース: ここにユーザーおよびプロジェクトのデータが格納されます。

  • Redis: 進行中のデータの高性能キャッシュとして機能し、主にプロジェクトの編集や共同作業に関連する情報を保持します。

  • Overleafファイルシステム: 編集不可のプロジェクトファイル(画像を含む)を保存し、プロジェクトのコンパイル中の一時ディスクキャッシュとしても機能します。

circle-info

これはおそらく ~/sharelatex_data または ~/overleaf_dataかもしれません。インスタンスがいつ設定されたかによります。

circle-check

ディスク上のフォルダレイアウトの詳細については、Folders in detailを参照してください。

一貫したバックアップの実行

一貫したバックアップを取得する際に含める必要があるストアは3つあります:

  • MongoDB

  • Redis

  • Overleafファイルシステムデータ

一貫したバックアップを作成するためには、 必須です バックアッププロセスが実行されている間にユーザーが新しいデータを作成できないようにすることを推奨します。したがって、ユーザーがインスタンスにアクセスしたりプロジェクトを編集したりできないメンテナンスウィンドウを予定することをお勧めします。

バックアッププロセスを開始する前に、インスタンスをオフラインにする必要があります。Server Proから始めて、 3.5.0 シャットダウンプロセスはサイトの閉鎖とユーザーの切断を自動化します。

インスタンスをシャットダウンするには、次を実行する必要があります bin/docker-compose stop sharelatex Toolkitデプロイメントを実行している場合、または docker compose stop sharelatex Docker Composeを実行している場合は。

コンテナが sharelatex 停止されたら、バックアッププロセスを開始できます。

バックアッププロセスが完了したら 正常に 次にコンテナを sharelatex 起動する必要があります。これを行うには次を実行します bin/docker-compose start sharelatex Toolkitデプロイメントを実行している場合、または docker compose start sharelatex Docker Composeを実行している場合は。

triangle-exclamation

MongoDB

MongoDBにはコマンドラインツール mongodumparrow-up-right が付属しており、データベースに保存されているユーザーおよびプロジェクトデータのバックアップを作成するために使用できます。

Overleafファイルシステムデータ

Toolkitデプロイメントの場合、編集不可ファイルが保存されるパスは環境変数で指定されますが、インスタンスが作成された時期によってはこれは config/overleaf.rc を使って OVERLEAF_DATA_PATH かもしれません data/sharelatex.

rsyncのようなツールを使用して rsync このディレクトリを再帰的にコピーすることが、完全なバックアップを作成するために必要です。

Redis

Redisはユーザーセッションと、MongoDBにフラッシュされる前の保留中のドキュメント更新を保存します。

Append Only File(AOF)永続性は、Redis永続化の推奨構成です。

ToolkitユーザーはデフォルトでAOF永続性が有効になっています( 新規 インストールの場合)。既存のユーザーはAOF有効化に関する詳細を見つけることができます こちら.

RDBスナップショットをAOF永続性と併用することを決めた場合、バックアップとしてRDBファイルを安全な場所にコピーすることができます。

サーバー間でのデータ移行

理想的には、新しいインスタンスにはまだ重要なデータがない方が良いです。インスタンスのデータをマージするためのプロセスは提供していません。

新しいインスタンスにまだデータがないと仮定すると、次のような手順に従うことができます。高レベルでは、私たちは mongo, redis および overleaf ボリュームの tar ボールを作成し、それを新しいサーバーにコピーして、そこで展開します。

Toolkit

Docker Compose

設定ファイルによっては、 docker-compose.yml ファイルのパスを mongo, redis, overleaf ボリュームのパスを調整する必要があるかもしれません。

circle-info

rootユーザー(またはsudoで)実行している場合、tarはファイルの所有者/グループおよびパーミッションを保持します。これはバックアップを復元する際に重要です。

フォルダの詳細

circle-info

次のフォルダには追加のヒントがあります:

  • (b) バックアップに含める。インスタンスを停止して一貫性を確保するのが最善です

  • (d) 削除可能

  • (e) エフェメラルなファイル。インスタンスを停止したときに削除可能

  1. ~/mongo_data (b)

    • mongodb データディレクトリ

  2. ~/redis_data (b)

    • redis データディレクトリ

  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)

        • 完全なプロジェクト履歴の移行のための一時ファイル

最終更新