> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Дані та резервні копії

Іноді в міру розвитку Overleaf нам потрібно змінювати схему даних у базі даних; для автоматизації цього процесу використовуються скрипти міграції. Спершу їх запускають на [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) — найбільшому екземплярі Overleaf у світі, — тож більшість можливих ситуацій уже траплялися, проте ми не надаємо жодних гарантій щодо ваших даних. Обов'язково створіть **узгоджену** резервну копію своїх даних **перед** оновленням екземпляра.

<Info>
  Під час оновлення до нового Docker-образу всі міграції, які **ще не** було виконано, запускаються автоматично; залежно від обсягу ваших даних це може зайняти певний час, а стежити за перебігом можна за журналами. Докладніше див. у нашій документації [Logging](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging).
</Info>

### Зберігання даних

Overleaf Community Edition і Server Pro зберігають свої дані у трьох окремих місцях:

* <strong>База даних MongoDB:</strong> тут зберігаються дані користувачів і проєктів.
* <strong>Redis:</strong> слугує високопродуктивним кешем для даних, що обробляються, переважно зберігаючи інформацію про редагування проєктів і співпрацю.
* <strong>Файлова система Overleaf:</strong> зберігає нередаговані файли проєктів (зокрема зображення), а також слугує тимчасовим дисковим кешем під час компіляції проєктів.

<Info>
  Це може бути `~/sharelatex_data` або `~/overleaf_data`, залежно від того, коли було налаштовано ваш екземпляр.
</Info>

<Check>
  Для файлів проєктів і даних повної історії проєктів ми також підтримуємо S3-сумісні бекенди зберігання.
</Check>

Докладніше про структуру каталогів на диску див. у розділі «Каталоги докладно».

### Створення узгодженої резервної копії

Під час створення узгодженої резервної копії потрібно включити три сховища:

* 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.

<Danger>
  * Резервні копії слід зберігати на іншому сервері, ніж той, на якому працює ваш екземпляр Overleaf, а в ідеалі — взагалі в іншому місці.
  * Реплікація баз даних на кілька екземплярів MongoDB може забезпечити певне резервування, але не захищає від пошкодження даних.
  * Тестування резервних копій — найкращий спосіб переконатися, що вони повні та працездатні.
</Danger>

### 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 [тут](/uk/on-premises/configuration/overleaf-toolkit/redis#enabling-append-only-file-persistence).

Якщо ви вирішите й надалі використовувати знімки RDB разом зі збереженням AOF, можна скопіювати файл RDB у безпечне місце як резервну копію.

### Перенесення даних між серверами

В ідеалі в новому екземплярі ще немає жодних цінних даних. Процесу об'єднання даних екземплярів у нас немає.

Якщо в новому екземплярі ще немає даних, ось кроки, яких можна дотримуватися. Загалом ми створюємо tar-архів томів `mongo`, `redis` і `overleaf`, копіюємо його на новий сервер і там знову розпаковуємо.

#### Toolkit

```bash theme={null}
# Gracefully shutdown the old instance
old-server$ bin/stop

# Create the tar-ball
old-server$ tar --create --file backup-old-server.tar config/ data/

# Copy the backup-old-server.tar file from the old-server to the
# new-server using any method that fits

# Gracefully shutdown new instance (if started yet)
new-server$ bin/stop

# Move new data, you can delete it too
new-server$ mkdir backup-new-server
new-server$ mv config/ data/ backup-new-server/

# Populate config/data dir again
new-server$ tar --extract --file backup-old-server.tar

# Start containers
new-server$ bin/up
```

#### Docker Compose

```bash wrap theme={null}
# Gracefully shutdown the old instance
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

# Create the tar-ball
old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data

# Copy the backup-old-server.tar file from the old-server to
# the new-server using any method that fits

# Gracefully shutdown new instance (if started yet)
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

# Move new data, you can delete it too
new-server$ mkdir backup-new-server
new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/

# Populate data dirs again
new-server$ tar --extract --file backup-old-server.tar

# Start containers
new-server$ docker start mongo redis
new-server$ docker start sharelatex
```

Залежно від вашого файлу **docker-compose.yml** може знадобитися скоригувати шляхи томів `mongo`, `redis`, `overleaf`.

<Info>
  Під час запуску від імені root (або через sudo) tar зберігає власника/групу файлів і права доступу, що критично важливо під час відновлення резервної копії.
</Info>

### Каталоги докладно

<Info>
  Наведені нижче каталоги мають додаткові позначки:

  * (b) включати до резервних копій, найкраще — коли екземпляр зупинено, щоб забезпечити узгодженість
  * (d) можна видалити
  * (e) тимчасові файли, можна видалити, коли екземпляр зупинено
</Info>

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)
         * тимчасові файли для міграцій повної історії проєктів


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.