Skip to main content

Migracja do S3

Te instrukcje dotyczą wersji v5.x i nowszych. Jeśli korzystasz z tego przewodnika dla wcześniejszej wersji, używaj sharelatex zamiast overleaf w nazwach ścieżek oraz prefiksu SHARELATEX_ zamiast OVERLEAF_ w zmiennych środowiskowych. W wersji v6 i nowszych pomiń starsze polecenia dotyczące user_files.
Chętnie poznamy Twoje doświadczenia! Jeśli chcesz podzielić się z nami informacją, ile plików przeniosłeś, jaki był ich łączny rozmiar i jak długo trwała migracja, napisz na ayaka-notes@outlook.com .
Ten przewodnik przeprowadzi Cię przez migrację z przechowywania danych na dysku do magazynu obiektów zgodnego z S3. Odwołuje się on do sekcji dokumentu wprowadzającego Konfiguracja S3.

Wymagania

  • Magazyn obiektów zgodny z S3, z którym można się komunikować — opcje opisano w #s3-setup
  • Wolne miejsce na dysku do migracji istniejących danych, mniej więcej równe obecnemu rozmiarowi danych na dysku
  • Okno serwisowe na przeprowadzenie właściwej migracji
  • Pełna kopia zapasowa, w tym konfiguracji, umożliwiająca przywrócenie z niej systemu

Oszacuj miejsce na dysku potrzebne do migracji

Do obliczenia bieżącego zużycia dysku możemy użyć du:
Jeśli na obecnym serwerze nie masz wystarczającej ilości wolnego miejsca, spróbuj podłączyć do serwera dodatkowy dysk.
Katalogi historii mają już właściwą strukturę. Możesz przesłać je bezpośrednio z zamontowanego folderu źródłowego (bind mount), co nie wymaga dodatkowego miejsca na dysku.

Kroki migracji

Krok 0: zatrzymaj instancję

Musimy mieć pewność, że wszystkie pliki użytkowników i szablonów zostaną przeniesione. Najlepiej zatrzymać instancję, aby nie pominąć nowo przesłanych plików. Procedurę zatrzymania opisano w naszym przewodniku dotyczącym wykonywania spójnej kopii zapasowej.

Krok 1: przekształć strukturę katalogów

Aby przesłać pliki projektów do S3, musimy przekształcić ich strukturę katalogów. Struktura katalogów w lokalnym magazynie filestore to <project-id>_<file-id>, a w S3 — <project-id>/<file-id>. W poniższych przykładach do przechowywania plików w nowej strukturze katalogów używany jest katalog /srv/overleaf-s3-migration. Zastąp /srv/overleaf-bind-mount katalogiem hosta zamontowanym w /var/lib/overleaf. Polecenia kopiowania uruchom na hoście z uprawnieniami do odczytu i zapisu tych katalogów; kontener pozostaje zatrzymany. Do przekształcenia struktury możemy użyć tar:

Krok 2: prześlij pliki

W zależności od preferencji do przesłania plików do magazynu obiektów zgodnego z S3 możesz użyć klienta S3 minio mc lub aws cli. aws cli
  • Zastąp overleaf-user-files, overleaf-template-files, overleaf-project-blobs i overleaf-chunks nazwami swoich bucketów S3.
  • Zastąp także /srv/overleaf-bind-mount lokalną ścieżką bind mountu /var/lib/overleaf. Domyślnie jest to ~/overleaf_data we wdrożeniu opartym na docker-compose.yml i <toolkit-checkout>/data/overleaf przy korzystaniu z Toolkit.
minio mc Używamy tutaj aliasu serwera “s3”; Ty mogłeś wybrać inną nazwę.

Krok 3: uruchom instancję skierowaną na S3

Dodaj do konfiguracji wszystkie zmienne związane z S3, zgodnie z sekcją Przegląd zmiennych w przewodniku konfiguracji S3. Zachowaj bind mount katalogu danych: może on zawierać także klucze szyfrowania Zotero lub Mendeley, które nie są migrowane do S3. Możesz teraz uruchomić instancję i zweryfikować migrację:
  • czy można wyświetlać podgląd plików binarnych w edytorze
  • czy można skompilować PDF z obrazami
  • czy można przesyłać nowe pliki

Wycofanie zmian

Migrację można bezpiecznie wycofać, wykonując kroki w odwrotnej kolejności:
  1. Zatrzymaj instancję
  2. Skopiuj pliki z powrotem, zamieniając kolejność źródła i celu
  3. Zapisz nowe pliki z powrotem w katalogu lokalnym, używając odwrotnego transform
  4. Uruchom ponownie instancję ze starą konfiguracją
Pierwsza transformacja usuwa folder najwyższego poziomu. Druga transformacja zmienia strukturę katalogów na płaską. Wzorce wildcards zapewniają, że wypakowywane są tylko pliki, a nie ich foldery nadrzędne (projektów).
Ostatnia modyfikacja 5 października 2026