> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/ja/mentenansu/data-and-backups.md).

# データとバックアップ

Overleaf を進化させるにつれて、データベース内のデータのスキーマを変更する必要があることがあります。この処理を自動化するために、マイグレーションスクリプトが使用されます。これらは次の環境で実行済みのはずです [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) まず、これは世界最大の Overleaf インスタンスなので、ほとんどの事態はすでに発生済みのはずですが、お客様のデータについては一切保証できません。必ず **整合性のある** データのバックアップ **前に** インスタンスをアップグレードする前に。

{% hint style="info" %}
新しい Docker イメージにアップグレードする際、まだ実行されていないマイグレーションは **しないでください** 自動的に実行されます。これはデータセットのサイズによっては時間がかかる場合がありますが、ログを追跡することで進捗を確認できます。詳細は、次を参照してください。 [ログ記録](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) ドキュメントを参照してください。
{% endhint %}

### データの保存

Overleaf Community Edition と Server Pro は、データを 3 つの別々の場所に保存します:

* **MongoDB データベース:** ユーザーとプロジェクトのデータが格納されています。
* **Redis:** 進行中のデータに対する高性能キャッシュとして機能し、主にプロジェクトの編集や共同作業に関する情報を保存します。
* **Overleaf のファイルシステム:** 編集不可のプロジェクトファイル（画像を含む）を保存し、プロジェクトのコンパイル中には一時ディスクキャッシュとしても機能します。

{% hint style="info" %}
これは `~/sharelatex_data` または `~/overleaf_data`、インスタンスがいつセットアップされたかによって異なります。
{% endhint %}

{% hint style="success" %}
プロジェクトファイルと完全なプロジェクト履歴データについては、S3 互換のストレージバックエンドもサポートしています。
{% endhint %}

ディスク上のフォルダ構成の詳細については、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 を使用している場合は

{% hint style="danger" %}

* バックアップは、Overleaf インスタンスが稼働しているサーバーとは別のサーバーに保存するべきであり、可能であればまったく別の場所に置くのが理想です。
* データベースを複数の MongoDB インスタンスに複製すると冗長性はある程度得られますが、破損からは保護されません。
* バックアップが完全で正常に機能することを確認する最善の方法は、実際にテストすることです。
  {% endhint %}

### MongoDB

MongoDB には次のようなコマンドラインツールがあります。 [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) これは、データベースに保存されているユーザーおよびプロジェクトデータのバックアップを作成するために使用できます。

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

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

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

### Redis

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

Redis の永続化には、Append Only File（AOF）永続化構成を推奨します。

Toolkit ユーザーでは、AOF 永続化が既定で有効になっています。 **新しい** インストール。既存ユーザーは、AOF を有効化する方法について詳しく [こちら](/on-premises/ja/she-ding/overleaf-toolkit/redis.md#enabling-append-only-file-persistence).

AOF 永続化とあわせて RDB スナップショットを引き続き使用する場合は、RDB ファイルを安全な場所にコピーしてバックアップとして保存できます。

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

少なくとも、新しいインスタンスにはまだ価値のあるデータが入っていないはずです。インスタンス同士のデータを統合する手順はありません。

新しいインスタンスにまだデータがないと仮定すると、以下の手順で進められます。大まかには、次の tarball を作成します。 `mongo`, `redis` および `Overleaf` ボリュームを新しいサーバーにコピーし、そこで再び展開します。

#### Toolkit

```bash
# 古いインスタンスを丁寧にシャットダウン
old-server$ bin/stop

# tarball を作成
old-server$ tar --create --file backup-old-server.tar config/ data/

# backup-old-server.tar ファイルを old-server から
# new-server に、適した方法でコピー

# 新しいインスタンスを丁寧にシャットダウン（まだ起動している場合）
new-server$ bin/stop

# 新しいデータを移動します。削除してもかまいません
new-server$ mkdir backup-new-server
new-server$ mv config/ data/ backup-new-server/

# config/data ディレクトリを再び元に戻す
new-server$ tar --extract --file backup-old-server.tar

# コンテナを起動
new-server$ bin/up
```

#### Docker Compose

```bash
# 古いインスタンスを丁寧にシャットダウン
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

# tarball を作成
old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data

# backup-old-server.tar ファイルを old-server から
# new-server に、適した方法でコピー

# 新しいインスタンスを丁寧にシャットダウン（まだ起動している場合）
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

# 新しいデータを移動します。削除してもかまいません
new-server$ mkdir backup-new-server
new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/

# データディレクトリを再び元に戻す
new-server$ tar --extract --file backup-old-server.tar

# コンテナを起動
new-server$ docker start mongo redis
new-server$ docker start sharelatex
```

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

{% hint style="info" %}
root ユーザーとして（または sudo で）実行すると、tar はファイルの所有者/グループと権限を保持します。これはバックアップを復元する際に重要です。
{% endhint %}

### フォルダの詳細

{% hint style="info" %}
次のフォルダには追加の注記があります:

* (b) バックアップに含める。整合性を確保するため、インスタンス停止時が最適
* (d) 削除可能
* (e) 一時ファイル。インスタンス停止時に削除可能
  {% endhint %}

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. キャッシュ (e)
         * コンパイル用のバイナリファイルキャッシュ
      2. コンパイル (e)
         * LaTeX のコンパイルはここで行われます
      3. db.sqlite (d)
         * 最新リリースでは未使用。以前は CLSI キャッシュの詳細を保存していました（単純なメモリ上のマップに移すか、ディスクをスキャンします）
      4. db.sqlite-wal (d)
         * 最新リリースでは未使用。db.sqlite を参照してください
      5. 出力 (e)
         * クライアントに提供するための LaTeX コンパイル出力の保存先
      6. template\_files (b)
         * テンプレートシステムの画像プレビュー（Server Pro のみ）
      7. user\_files (b)
         * プロジェクトのバイナリファイル
      8. history (b)
         * 完全なプロジェクト履歴ファイル
   3. tmp
      1. dumpFolder (e)
         * zip ファイル処理時の一時ファイル
      2. uploads (e)
         * ファイルアップロードのバッファリング（バイナリファイル/new-project-from-zip アップロード）
      3. projectHistories (e)
         * 完全なプロジェクト履歴のマイグレーション用一時ファイル


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ayakaleaf-pro.ayaka.space/on-premises/ja/mentenansu/data-and-backups.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.