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

Іноді в міру розвитку Overleaf нам потрібно змінювати схему даних у базі даних; для автоматизації цього процесу використовуються скрипти міграції. Спершу їх запускають на overleaf.com — найбільшому екземплярі Overleaf у світі, — тож більшість можливих ситуацій уже траплялися, проте ми не надаємо жодних гарантій щодо ваших даних. Обов’язково створіть узгоджену резервну копію своїх даних перед оновленням екземпляра.

Під час оновлення до нового Docker-образу всі міграції, які ще не було виконано, запускаються автоматично; залежно від обсягу ваших даних це може зайняти певний час, а стежити за перебігом можна за журналами. Докладніше див. у нашій документації Logging.

​

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

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

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

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

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

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

​

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

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

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

• Резервні копії слід зберігати на іншому сервері, ніж той, на якому працює ваш екземпляр 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 тут.

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

​

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

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

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

​

Toolkit

# 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

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

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

​

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

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

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