Skip to main content

Міграція на S3

Ці інструкції призначені для v5.x і новіших версій. Якщо ви виконуєте цей посібник для ранішої версії, використовуйте sharelatex замість overleaf у шляхах і префікс SHARELATEX_ замість OVERLEAF_ у змінних середовища. Для v6 і новіших версій пропустіть застарілі команди для user_files.
Ми будемо раді почути від вас! Якщо ви хочете поділитися з нами, скільки файлів ви перенесли, який їхній загальний обсяг і скільки часу тривала міграція, напишіть на ayaka-notes@outlook.com.
Цей посібник проведе вас через міграцію з дискового сховища на об’єктне сховище, сумісне з S3. У ньому є посилання на розділи вступного документа Налаштування S3.

Вимоги

  • Сумісне з S3 об’єктне сховище, з яким буде працювати система; варіанти дивіться в #s3-setup
  • Вільне місце на диску для міграції наявних даних — приблизно стільки, скільки дані займають на диску зараз
  • Вікно технічного обслуговування для проведення самої міграції
  • Повна резервна копія, включно з конфігурацією, щоб мати змогу відновитися з неї

Оцінка дискового простору, потрібного для міграції

Для обчислення поточного використання диска можна скористатися du:
Якщо на поточному сервері недостатньо вільного місця на диску, спробуйте під’єднати до сервера ще один диск.
Каталоги історії вже мають правильну структуру. Ви можете завантажувати їх безпосередньо з вихідної папки, змонтованої через bind-mount, що не потребує додаткового дискового простору.

Кроки міграції

Крок 0: зупиніть екземпляр

Потрібно переконатися, що буде перенесено всі файли користувачів і шаблонів. Найкраще зупинити екземпляр, щоб не пропустити нещодавно завантажені файли. Порядок зупинки описано в нашому посібнику зі створення узгодженої резервної копії.

Крок 1: змініть структуру каталогів

Для завантаження файлів проєктів у S3 потрібно змінити структуру їхніх каталогів. Структура каталогів для локального сховища у filestore має вигляд <project-id>_<file-id>, а в S3 — <project-id>/<file-id>. Далі для зберігання файлів у новій структурі каталогів використовується /srv/overleaf-s3-migration. Замініть /srv/overleaf-bind-mount каталогом хоста, змонтованим у /var/lib/overleaf. Виконуйте команди копіювання на хості з правами на читання й запис цих каталогів; контейнер залишається зупиненим. Для зміни структури можна скористатися tar:

Крок 2: завантажте файли

Залежно від ваших уподобань для завантаження файлів у сумісне з S3 об’єктне сховище можна використати S3-клієнт minio mc або aws cli. aws cli
  • Тут слід замінити overleaf-user-files, overleaf-template-files, overleaf-project-blobs і overleaf-chunks назвами ваших бакетів S3.
  • Також замініть /srv/overleaf-bind-mount локальним шляхом bind-mount для /var/lib/overleaf. Типово це ~/overleaf_data у розгортанні з docker-compose.yml і <toolkit-checkout>/data/overleaf під час використання Toolkit.
minio mc Тут ми використовуємо псевдонім сервера “s3”; можливо, ви вибрали іншу назву.

Крок 3: запустіть екземпляр, налаштований на S3

Додайте до своєї конфігурації всі змінні, пов’язані з S3, як описано в розділі Огляд змінних посібника з налаштування S3. Залиште bind-mount каталогу даних: він також може містити ключі шифрування Zotero або Mendeley, які не переносяться до S3. Тепер можна запустити екземпляр і перевірити міграцію:
  • у редакторі відображається попередній перегляд бінарних файлів
  • вдається скомпілювати PDF із зображеннями
  • вдається завантажувати нові файли

Відкат

Міграцію можна коректно відкотити, виконавши кроки у зворотному порядку:
  1. Зупиніть екземпляр
  2. Віддзеркальте файли назад, помінявши місцями джерело й призначення
  3. Запишіть нові файли назад у локальний каталог за допомогою зворотного transform
  4. Перезапустіть екземпляр зі старою конфігурацією
Перше перетворення видаляє папку верхнього рівня. Друге перетворення змінює структуру каталогів на плоску. Шаблони (wildcards) гарантують, що буде витягнуто лише файли, а не їхні батьківські папки (проєктів).
Останнє оновлення 5 жовтня 2026 р.