Skip to main content
Overleaf’i geliştirdikçe zaman zaman veritabanındaki verilerin şemasını değiştirmemiz gerekir; bu süreci otomatikleştirmek için taşıma (migration) betikleri kullanılır. Bu betikler önce dünyanın en büyük Overleaf örneği olan overleaf.com üzerinde çalıştırılmış olacağından olası durumların çoğuyla zaten karşılaşılmıştır; ancak verileriniz konusunda hiçbir garanti vermiyoruz. Lütfen örneğinizi yükseltmeden önce verilerinizin tutarlı bir yedeğini aldığınızdan emin olun.
Yeni bir Docker imajına yükseltirken, henüz çalıştırılmamış olan tüm taşımalar otomatik olarak yürütülür; bu işlem veri kümenizin boyutuna bağlı olarak biraz zaman alabilir. Günlükleri takip ederek ilerlemeyi görebilirsiniz. Daha fazla bilgi için Günlükleme dokümantasyonumuza bakın.

Veri depolama

Overleaf Community Edition ve Server Pro verilerini üç ayrı yerde depolar:
  • MongoDB Veritabanı: Kullanıcı ve proje verilerinin bulunduğu yerdir.
  • Redis: İşlem hâlindeki veriler için yüksek performanslı bir önbellek görevi görür; öncelikle proje düzenlemeleri ve işbirliğiyle ilgili bilgileri depolar.
  • Overleaf Dosya Sistemi: Düzenlenemeyen proje dosyalarını (görseller dahil) depolar ve proje derlemeleri sırasında geçici bir disk önbelleği olarak da işlev görür.
Bu, örneğinizin ne zaman kurulduğuna bağlı olarak ~/sharelatex_data veya ~/overleaf_data olabilir.
Proje dosyaları ve tam proje geçmişi verileri için S3 uyumlu depolama arka uçlarını da destekliyoruz.
Diskteki klasör düzeni hakkında daha fazla bilgi için Klasörlerin ayrıntıları bölümüne bakın.

Tutarlı bir yedekleme alma

Tutarlı bir yedek alırken dahil edilmesi gereken üç depo vardır:
  • MongoDB
  • Redis
  • Overleaf Dosya Sistemi verileri
Tutarlı bir yedek oluşturmak için, yedekleme işlemi sürerken kullanıcıların yeni veri üretmesini engellemek zorunludur. Bu nedenle, kullanıcıların örneğe erişemeyeceği veya projelerini düzenleyemeyeceği bir bakım penceresi planlamanızı öneririz. Yedekleme işlemine başlamadan önce örneğinizi çevrimdışı duruma getirmeniz gerekir. Server Pro 3.5.0 sürümünden itibaren kapatma işlemi, sitenin kapatılmasını ve kullanıcıların bağlantısının kesilmesini otomatikleştirir. Örneğinizi kapatmak için, Toolkit dağıtımı çalıştırıyorsanız bin/docker-compose stop sharelatex, Docker Compose çalıştırıyorsanız docker compose stop sharelatex komutunu çalıştırmanız gerekir. sharelatex konteyneri durdurulduktan sonra yedekleme işlemine başlayabilirsiniz. Yedekleme işlemi başarıyla tamamlandıktan sonra sharelatex konteynerini başlatmanız gerekir. Bunu yapmak için, Toolkit dağıtımı çalıştırıyorsanız bin/docker-compose start sharelatex, Docker Compose çalıştırıyorsanız docker compose start sharelatex komutunu çalıştırın.
  • Yedekler, Overleaf örneğinizin çalıştığı sunucudan ayrı bir sunucuda, ideal olarak tamamen farklı bir konumda saklanmalıdır.
  • Veritabanlarını birden çok MongoDB örneğine çoğaltmak bir miktar yedeklilik sağlayabilir, ancak veri bozulmasına karşı koruma sağlamaz.
  • Yedeklerinizi test etmek, eksiksiz ve işlevsel olduklarından emin olmanın en iyi yoludur.

MongoDB

MongoDB, veritabanında depolanan kullanıcı ve proje verilerinin yedeğini oluşturmak için kullanılabilen mongodump adlı bir komut satırı aracıyla birlikte gelir.

Overleaf Dosya Sistemi verileri

Toolkit dağıtımlarında, düzenlenemeyen dosyalarınızın depolandığı yol config/overleaf.rc içinde OVERLEAF_DATA_PATH ortam değişkeniyle belirtilir; ancak örneğinizin ne zaman oluşturulduğuna bağlı olarak bu data/sharelatex olabilir. Eksiksiz bir yedek oluşturulduğundan emin olmak için bu dizini rsync gibi bir araçla özyinelemeli olarak kopyalamanız gerekir.

Redis

Redis, kullanıcı oturumlarını ve MongoDB’ye aktarılmadan önce bekleyen belge güncellemelerini depolar. Redis kalıcılığı için önerilen yapılandırma Append Only File (AOF) kalıcılığıdır. Toolkit kullanıcılarında yeni kurulumlar için AOF kalıcılığı varsayılan olarak etkindir; mevcut kullanıcılar AOF’yi etkinleştirme hakkında daha fazla bilgiyi burada bulabilir. AOF kalıcılığıyla birlikte RDB anlık görüntülerini kullanmaya devam etmeye karar verirseniz, RDB dosyasını yedek olarak güvenli bir konuma kopyalayabilirsiniz.

Sunucular arasında veri taşıma

En iyi durumda, yeni örnekte henüz değerli bir veri bulunmaz. Örneklerin verilerini birleştirmek için bir sürecimiz yoktur. Yeni örnekte henüz veri olmadığını varsayarsak, izleyebileceğiniz bazı adımlar şunlardır. Genel hatlarıyla, mongo, redis ve overleaf volume’larının bir tar arşivini oluşturur, bunu yeni sunucuya kopyalar ve orada yeniden açarız.

Toolkit

Docker Compose

docker-compose.yml dosyanıza bağlı olarak mongo, redis, overleaf volume’larının yollarını ayarlamanız gerekebilir.
root kullanıcısı olarak (veya sudo ile) çalıştırıldığında tar, dosya sahibi/grubu ve izinlerini korur; bu, yedeği geri yüklerken kritik öneme sahiptir.

Klasörlerin ayrıntıları

Aşağıdaki klasörlerde ek ipuçları bulunur:
  • (b) yedeklere dahil edin; tutarlılığı sağlamak için en iyisi örnek durdurulmuşken yapmaktır
  • (d) silinebilir
  • (e) geçici dosyalar; örnek durdurulduğunda silinebilir
  1. ~/mongo_data (b)
    • mongodb veri dizini
  2. ~/redis_data (b)
    • redis veritabanı veri dizini
  3. ~/overleaf_data
    1. bin
      1. synctex (d)
        • son sürümde kullanılmıyor; önceden özel bir synctex ikili dosyası kullanılıyordu (synctex, .tex dosyaları ile pdf arasında kaynak eşlemesi için kullanılır)
    2. data
      1. cache (e)
        • derlemeler için ikili dosya önbelleği
      2. compiles (e)
        • latex derlemesi burada gerçekleşir
      3. db.sqlite (d)
        • son sürümde kullanılmıyor; önceden clsi önbellek ayrıntılarını depoluyordu (bunlar ya basit bellek içi eşlemelere taşındı ya da diski tarıyoruz)
      4. db.sqlite-wal (d)
        • son sürümde kullanılmıyor, bkz. db.sqlite
      5. output (e)
        • istemciye sunulmak üzere latex derleme çıktısı deposu
      6. template_files (b)
        • şablon sisteminin görsel önizlemeleri (yalnızca Server Pro)
      7. user_files (b)
        • projelerin ikili dosyaları
      8. history (b)
        • tam proje geçmişi dosyaları
    3. tmp
      1. dumpFolder (e)
        • zip dosyalarının işlenmesinden kalan geçici dosyalar
      2. uploads (e)
        • dosya yüklemelerinin arabelleğe alınması (ikili dosya/zip’ten yeni proje yüklemesi)
      3. projectHistories (e)
        • tam proje geçmişi taşımaları için geçici dosyalar
Son değiştirilme tarihi 5 Ekim 2026