> For the complete documentation index, see [llms.txt](https://overleaf-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://overleaf-pro.ayaka.space/on-premises/ko/support/support-guides/doc-version-recovery.md).

# (v5.0.1 마이그레이션) 문서 버전 복구

{% hint style="info" %}
Server Pro 버전 5.0.1 또는 Community Edition 버전 5.0.1을 한 번도 실행한 적이 없거나, 5.0.1로 완전히 새 인스턴스를 시작한 경우에는 이 복구 절차를 실행할 필요가 없습니다.
{% endhint %}

**이 페이지의 업데이트:**

* (2024-04-22 13:40 BST): "시스템에 새 업데이트가 들어오는 것을 중지하고 모든 변경 사항을 MongoDB에 플러시" 단계를 추가했습니다.
* (2024-04-23 11:45 BST): 5.0.1에서 손상된 플러시를 처리하고, 5.0.2가 시작된 경우 플러시를 건너뜁니다.

복구에 걸리는 시간은 인스턴스 내 프로젝트의 수와 크기, 그리고 다음에 정의된 청크용 히스토리 저장소에서 사용되는 저장 백엔드에 따라 달라집니다( `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

복구 과정은 Server Pro 컨테이너 내부에서 애플리케이션 시작을 지연시킵니다. 그동안 사이트는 오프라인으로 표시됩니다. 복구는 Server Pro 컨테이너의 단일 인스턴스에서만 실행하도록 지원하며, 다른 모든 수평 확장 워커는 오프라인 상태여야 합니다.

필요하면 복구 과정을 중지하고 다시 시작할 수 있습니다.

성능 테스트에 따르면, 복구 과정은 최신 하드웨어(3GHz CPU 클럭 속도와 로컬 NVMe 저장소)에서 분당 약 1만 개의 작은 프로젝트를 처리할 수 있습니다. 예를 들어 10만 개의 프로젝트가 있는 인스턴스의 경우 최소 10분+2분의 다운타임을 허용하는 유지보수 창을 예약하세요. 인스턴스의 프로젝트 수를 추정하려면 다음 쿼리를 사용하세요:

{% code overflow="wrap" %}

```bash
$ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()'
```

{% endcode %}

시작하기 전에 다음 복구 단계를 끝까지 모두 읽어 주세요. Server Pro 고객은 언제든지 <support@overleaf.com> 으로 문의하셔도 됩니다.

### 복구 절차

{% stepper %}
{% step %}

#### 릴리스 이미지를 가져오기

다음 `5.0.3` 릴리스 이미지를 가져오세요.
{% endstep %}

{% step %}

#### 몇 개의 프로젝트 식별

히스토리가 없는 몇 개의 프로젝트를 ID로 식별하세요. 가능하다면 그중 하나를 변경할 수 있는 권한이 있어야 합니다.
{% endstep %}

{% step %}

#### 유지보수 일정 잡기

다운타임을 위한 유지보수 창을 예약하세요.
{% endstep %}

{% step %}

#### 한 워커만 제외하고 모두 중지

수평 확장 설정을 사용할 때는 한 워커만 제외하고 모두 중지하세요.
{% endstep %}

{% step %}

#### 새 업데이트를 중지하고 모든 변경 사항을 MongoDB에 플러시

시스템에 새 업데이트가 들어오는 것을 중지하고 모든 변경 사항을 MongoDB에 플러시하세요:

1. 편집기를 닫고 관리 패널을 통해 모든 사용자를 수동으로 연결 해제하세요 `https://my-server-pro.example.com/admin#open-close-editor` 의 "Open/Close Editor" 탭에서.
2. Websocket/실시간 서비스를 중지하세요.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. 다음에 표시되는 것처럼 실시간 서비스가 종료될 때까지 기다리세요 `down:`.

   ```bash
   $ docker exec sharelatex sv status real-time-overleaf
   run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
   # 조금 더 기다리세요...

   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normally up
   ```
4. 활성화되어 있다면 git-bridge 컨테이너를 중지하세요.

   ```bash
   $ docker stop git-bridge
   ```
5. 5.0.2를 한 번도 실행한 적이 없다면: 문서 업데이트에 대해 수동 플러시를 실행하고 성공할 때까지 기다리세요.

   오류가 나면 명령을 반복할 수 있습니다. 연속 실행에서 0이 아닌 `failureCount` 가 표시되면 마이그레이션을 중지하고( `docker restart git-bridge sharelatex`를 통해 서비스를 복원한 뒤) 지원팀에 문의하세요.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex bash -c 'source /etc/container_environment.sh &#x26;&#x26; source /etc/overleaf/env.sh &#x26;&#x26; cd services/document-updater &#x26;&#x26; LOG_LEVEL=info node scripts/flush_all.js'
   ...
   {"name":"default","hostname":"...","pid":324,"level":30,"successCount":...,"failureCount":0,"msg":"모든 프로젝트 플러시 완료","time":"...","v":0}
   모든 프로젝트 플러시 완료
   </code></pre>
6. 5.0.2를 한 번도 실행한 적이 없다면: 모든 변경 사항이 redis에서 플러시되었는지 확인하세요.

   다음의 출력이 있으면 `redis-cli`가 출력되면 마이그레이션을 중지하고( `docker restart git-bridge sharelatex`를 통해 서비스를 복원한 뒤) 지원팀에 문의하세요.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # redis-cli의 출력이 없으면 성공입니다. 다음으로 redis-cli의 종료 코드를 확인하세요. 0이어야 합니다.
   $ echo $?
   0
   </code></pre>
7. 보류 중인 히스토리 변경 사항을 플러시해 보세요.

   이 작업은 최선을 다해 플러시해야 합니다. 일부 프로젝트는 잘못된 데이터베이스 마이그레이션 때문에 히스토리가 손상되어 있습니다. 실패한 항목은 복구 과정이 끝날 때 히스토리를 다시 동기화하여 처리합니다.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex bash -c 'source /etc/container_environment.sh &#x26;&#x26; source /
   </code></pre>

{% endstep %}

{% step %}

#### 백업을 만들기

다음과 같은 [일관된 백업](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) 인스턴스의 백업을 고려하세요.
{% endstep %}

{% step %}

#### 업그레이드

버전으로 업그레이드 `5.0.3`.
{% endstep %}

{% step %}

#### 자동 복구

복구 과정은 컨테이너 시작 시 자동으로 실행됩니다.
{% endstep %}

{% step %}

#### 진행 상황 확인

다음 로그 파일을 tail로 확인하여 스크립트의 진행 상황을 추적할 수 있습니다 `/var/lib/overleaf/data/history/doc-version-recovery.log`. 시작 시 총 프로젝트 수를 출력하고, 처리된 프로젝트가 1000개마다 요약을 출력합니다.

{% code overflow="wrap" %}

```bash
$ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
```

{% endcode %}
{% endstep %}

{% step %}

#### 복구 과정이 끝날 때까지 기다리세요

위의 로그 파일을 tail로 확인하여 `완료.` 줄이 출력될 때까지 기다리거나 `doc 버전 복구가 완료되었습니다.` 가 Server Pro 컨테이너의 표준 출력에 출력될 때까지 기다리세요.
{% endstep %}

{% step %}

#### 복구 과정 검증

이전에 히스토리가 없던 몇몇 프로젝트에서 히스토리 패널을 열어 복구 과정을 검증하세요.

1. 테스트할 프로젝트의 재동기화를 앞당기세요(언젠가는 처리되지만, 차례가 올 때까지 기다리고 싶지는 않습니다.)

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true"
   </code></pre>

   (테스트할 각 project-id에 대해 반복하고, `000000000000000000000000` 를 한 번에 하나의 project-id로 바꿔 넣으세요.)
2. 프로젝트 `https://my-server-pro.example.com/project/000000000000000000000000`
3. 프로젝트의 "History" 패널을 열어 최신 콘텐츠를 확인하세요.
4. 선택 사항: "History" 패널을 다시 닫으세요. 헤더에 주석을 추가하는 등의 코드 변경을 하세요.
5. 선택 사항: 재컴파일을 실행하여 로컬 변경 사항의 플러시를 트리거하세요. "History" 패널을 다시 열어 변경 사항을 확인하세요. 완료되면 변경 사항을 되돌리세요.
   {% endstep %}

{% step %}

#### 수평 확장인 경우...

다른 워커를 다시 시작하세요.
{% endstep %}

{% step %}

#### 인스턴스를 계속 실행 상태로 유지

복구 과정을 실행한 인스턴스는 계속 실행 상태로 유지해 주세요. 그러면 모든 프로젝트의 히스토리가 백그라운드에서 동시성 1로 다시 동기화됩니다. 이로 인해 기본 부하가 약간 증가합니다. (인스턴스를 재시작할 수는 있지만, 그러면 재동기화를 처음부터 다시 시작해야 합니다.)
{% endstep %}

{% step %}

#### 완료되면 알려 주세요

Server Pro 고객: 복구 과정을 완료하면 지원팀에 알려 주세요.
{% endstep %}
{% endstepper %}


---

# 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://overleaf-pro.ayaka.space/on-premises/ko/support/support-guides/doc-version-recovery.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.