Dockup'ta Kalıcı Volume'lar ve Snapshot'lar
Dockup'ta kalıcı volume'lar ve snapshot'lar: mount path'lerini seçin, kullanımı inceleyin, snapshot alın ve zamanlayın, güvenle geri yükleyin ve kalıcı verileri koruyun.
Kalıcı volume'lar ve snapshot'lar iki farklı sorunu çözer. Bir volume, container değiştirildiğinde veya yeniden deployment yapıldığında dosyaları korur. Snapshot ise volume'un belirli bir zamandaki durumunu kaydeder; böylece operatörler bu durumu daha sonra inceleyebilir, saklayabilir veya geri yükleyebilir.
Container filesystem'ı değiştirilebilir. Bir deployment sonrasında da korunması gereken her şeyin (yüklemeler, oluşturulan medya dosyaları, index'ler, package artifact'leri veya uygulamanın yönettiği dosyalar) açıkça tanımlanmış kalıcı bir konumda tutulması gerekir.
Hangi uygulama verileri kalıcı depolamada tutulmalıdır?
Uygulama başka bir kaynaktan kolayca veya güvenli bir şekilde yeniden oluşturamayacağı dosyaların sahibi olduğunda volume kullanın.
| Veri | Volume? | Kullanılabiliyorsa daha iyi alternatif |
|---|---|---|
| Kullanıcı yüklemeleri | Evet | Mimari kullanıyorsa object storage |
| Oluşturulan thumbnail'ler | Belki | Orijinallerden yeniden oluşturma |
| Search index'i | Belki | Kaynak database'den yeniden oluşturma |
| Build artifact'leri | Genellikle hayır | Deployment sırasında yeniden build etme |
| Uygulama log'ları | Genellikle hayır | Runtime log sistemi |
| PostgreSQL data directory'si | Uygulama volume'u olarak değil | Managed PostgreSQL |
| Geçici cache | Hayır | Redis veya ephemeral storage |
| Local SQLite production DB | Riskli | Concurrency ve backup'lar için managed database |
Her volume'un tek ve net bir sahibi ile mount path'i olmalıdır. Birbiriyle ilgisiz iki process'in aynı directory'ye yazması, recovery ve permission analizini zorlaştırır.
Storage eklemeden önce başlangıç boyutunu, büyüme hızını, retention gereksinimlerini ve recovery hedefini tahmin edin. Disk kullanımı, plan bakiyesine göre dakika başına ölçülür; bu nedenle kullanılmayan kapasitenin ve kontrolsüz dosya büyümesinin bir maliyeti vardır.
Dockup volume'u nasıl oluşturulur ve incelenir?
Tam service için mevcut volume'ları listeleyin:
dockup volume list production/web --json
Bir volume'u name, absolute container path ve gigabyte cinsinden size bilgisiyle ekleyin:
dockup volume add production/web \
--name uploads \
--path /app/uploads \
--size 20 \
--json
Uygulama /app/uploads konumuna yazmalıdır. /uploads veya başka bir local directory'ye yazmak, dosyaları otomatik olarak mount içine yönlendirmez.
Deployment sonrasında uygulamanın, değiştirilebilir container filesystem'ı yerine tanımlanan absolute mount path'e yazdığını doğrulayın.
Dönen volume ID ile gerçek disk kullanımını inceleyin:
dockup volume usage <volumeId> production/web --json
Gerçek kullanımı ayrılan size ve uygulama metrikleriyle karşılaştırın. Filesystem dolmadan önce alert oluşturun; dolu bir volume kısmi yazmalara, başarısız yüklemelere veya uygulama crash'lerine neden olabilir.
File ownership beklentilerini gözden geçirin. Container'ın runtime user'ı, gerekenden daha geniş permission'lar vermeden mount path'i okuyup yazabilmelidir.
Volume snapshot'ları verileri nasıl korur?
İsteğe bağlı bir snapshot, volume içeriğini kaydeder:
dockup volume snapshot <volumeId> production/web --json
Kullanılabilir snapshot'ları listeleyin:
dockup volume snapshots <volumeId> production/web --json
Snapshot'lar volume'u read-only şekilde okur ve uygulamanın özel bir snapshot directory'sine yazmasını gerektirmez. Riskli bir file migration, toplu medya yeniden yazma işlemi veya saklanan verileri dönüştüren bir uygulama değişikliğinden önce kullanışlıdır.
Bir volume snapshot'ı otomatik olarak application-consistent değildir. Uygulama birbiriyle ilişkili birkaç dosyaya aynı anda yazıyorsa snapshot bunları biraz farklı zaman noktalarında yakalayabilir. Managed database için raw data directory'nin snapshot'ını almak yerine managed database backup sistemini kullanın.
Uygulamanın ne zaman quiesce edilmesi gerektiğini belirleyin. Değerli bir snapshot öncesinde kısa bir maintenance veya write pause uygun olabilir. Snapshot ID'sini, nedenini ve beklenen restore point'i kaydedin.
Snapshot retention nasıl planlanmalıdır?
Snapshot zamanlamasını ve retention'ı alışkanlığa göre değil, recovery gereksinimine göre belirleyin. Her riskli file migration, cleanup veya format değişikliğinden önce isteğe bağlı bir snapshot oluşturun ve dönen snapshot ID'sini kaydedin.
dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json
| Recovery ihtiyacı | Snapshot uygulaması | Sınırlama |
|---|---|---|
| Bir file migration'ı geri almak | Değişiklikten hemen önce snapshot alın | Sonraki yazmaları içermez |
| Geçmiş noktaları korumak | Policy kapsamında etiketlenmiş recovery point'leri saklayın | Retention aktif olarak gözden geçirilmelidir |
| Sık yazmaları korumak | Veriye uygun application-level backup ekleyin | Point-in-time snapshot sürekli koruma değildir |
| Mevzuata uygun arşiv | Özel bir arşiv workflow'u kullanın | Operasyonel snapshot'lar policy gereksinimlerini karşılamayabilir |
Beklenen snapshot'ların gerçekten mevcut olup olmadığını kontrol edin. Yazılı bir retention policy'si, kullanılabilir bir restore point oluşturulduğunun kanıtı değildir.
Volume snapshot'ı güvenle nasıl geri yüklenir?
Bir restore işlemi mevcut volume içeriğinin yerini alır ve container'ı yeniden başlatır:
dockup volume restore \
<volumeId> \
<snapshotId> \
production/web \
--json
Bu, kesintiye neden olan ve durumu değiştiren bir işlemdir. Restore işleminden önce:
- Tam service'i, volume ID'sini ve snapshot ID'sini doğrulayın.
- Hangi mevcut dosyaların değiştirileceğini açıklayın.
- Mümkünse yeni yazmaları durdurun veya sınırlayın.
- Gerekebilecekse mevcut durumun yeni bir snapshot'ını alın.
- Uygulama ve schema uyumluluğunu kaydedin.
- Production için açık onay alın.
- Restore sonrası doğrulama planlayın.
Restore sonrasında container durumunu ve uygulamanın davranışını doğrulayın:
dockup status production/web --json
dockup logs production/web --json
Temsili dosyaları, permission'ları, index'leri ve uygulama referanslarını test edin. Başarılı bir restore komutu snapshot'ın uygulandığını kanıtlar; ancak her uygulama kaydının geçerli bir dosyaya işaret ettiğini kanıtlamaz.
AI agent production guardrails modeli, bunun bir recovery işlemi olmasına rağmen restore'u onay gerektiren bir işlem olarak ele almalıdır.
Deployment ve rollback sırasında volume'lar nasıl davranmalıdır?
Bir deployment, mount edilmiş volume kalırken uygulama container'larını değiştirir. Bu, yeni image'ın mevcut dosyaları görmesini sağlar; ancak bir uyumluluk zorunluluğu oluşturur.
Yeni bir uygulama sürümü, release'i doğrulanmadan önce saklanan dosyaları geri döndürülemez biçimde dönüştürmemelidir. Dosya formatlarını veya directory layout'larını değiştiriyorsa mümkün olduğunda resumable ve backward-compatible bir migration kullanın.
Application rollback, eski bir deployment'ı yeniden çalıştırır:
dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json
Volume, image ile birlikte otomatik olarak rollback edilmez. Eski bir uygulama, yeni sürüm tarafından dönüştürülmüş dosyaları okuyamayabilir. Image rollback ile snapshot restore işlemlerini yalnızca her ikisi de gerektiğinde ve onaylandığında birlikte planlayın.
Bu ayrım önemlidir:
| Recovery işlemi | Image'ı değiştirir mi? | Volume verisini değiştirir mi? |
|---|---|---|
| Yeni sürüm deploy etme | Evet | Hayır, uygulama migrate etmediği sürece |
| Deployment'ı rollback etme | Evet | Hayır |
| Snapshot'ı restore etme | Hayır | Evet |
| Restore ve rollback birlikte | Evet | Evet |
Zero-downtime deployment süreci traffic cutover'ını korur; veri formatı uyumluluğunu değil.
Kalıcı storage için operasyon runbook'u nedir?
Her production volume'u için bir owner belirleyin. Runbook şunları içermelidir:
- Service target'ı ve volume ID'si.
- Mount path ve beklenen runtime user.
- Ayrılan size ve alert threshold'u.
- Veri açıklaması ve yeniden oluşturulabilirlik durumu.
- Snapshot schedule'ı ve retention.
- Son doğrulanmış snapshot.
- Restore onay policy'si.
- Uygulama doğrulama adımları.
- Image ve veri uyumluluğu notları.
- Büyüme ve silme policy'si.
Kullanımı düzenli olarak inceleyin:
dockup volume usage <volumeId> production/web --json
CPU, RAM ve disk dakika başına ölçülür. Free plan, başlangıç kredisi olarak $10 sunar; önerilen Pro planı ise aylık $20 tutar ve $20 kullanım kredisi içerir.
Snapshot restore tatbikatı
Hangi snapshot'ın seçileceğini kimsenin bilmediğini keşfetmek için bir incident beklemeyin. Production dışı bir service veya onaylanmış bir kopya üzerinde kontrollü bir tatbikat gerçekleştirin:
- Kolayca tanınabilen test dosyaları oluşturun.
- Bir snapshot alın.
- Dosyaları değiştirin.
- Snapshot'ı restore edin.
- İçeriği ve permission'ları doğrulayın.
- Container'ın yeniden başlatılmasını gözlemleyin.
- Süreyi ve hata noktalarını kaydedin.
Bir restore tatbikatı, kalıcı volume'ları ve snapshot'ları bir checkbox olmaktan çıkarıp test edilmiş bir recovery yeteneğine dönüştürür.
İlk service tasarımı için Git repository to production içeriğine bakın. Komut ayrıntıları için Dockup CLI reference sayfasını kullanın.
Dosya verileri için recovery objective'lerini tanımlayın
Recovery point objective, işletmenin ne kadar yakın tarihli veriyi kaybedebileceğini belirtir. Recovery time objective ise geri yüklemenin ne kadar sürebileceğini belirtir. Yedi kopya retention'ına sahip günlük bir snapshot, dahili bir medya cache'i için yeterli olabilir; ancak neredeyse gerçek zamanlı durability taahhüdü veren bir user-upload ürünü için yeterli olmayabilir.
Her iki değeri de dokümante edin ve gerçek restore süresini test edin. Snapshot oluşturma hızı, veri boyutu, container restart'ı, dosya doğrulama ve uygulamanın yeniden index'lenmesi recovery süresine katkıda bulunur.
Dosya silme ve büyümesini kontrol edin
Uygulama geçici veya değiştirilmiş dosyaları hiç silmediği için kalıcı storage dolabilir. Uygulama katmanında bir retention policy ekleyin ve logical deletion ile anında physical deletion'ı birbirinden ayırın. Kısa bir recovery window, kalıcı silme işlemini ertelemeyi gerektirebilir.
Toplu bir cleanup çalıştırmadan önce:
- Mevcut volume kullanımını ölçün.
- Silinecek adayların listesini oluşturun.
- Bir snapshot alın.
- Cleanup'ı sınırlandırılmış batch'ler halinde çalıştırın.
- Uygulama referanslarını doğrulayın.
- Beklenen alan kazanımını onaylayın.
Bu yaklaşım, kalıcı volume'lara ve snapshot'lara yalnızca incident sırasında değil, önleyici bir rol de kazandırır.
Snapshot envanterini doğrulayın
Snapshot ID'lerini, oluşturulma zamanlarını, retention bilgilerini ve son başarılı restore testini belirli aralıklarla gözden geçirin. Yakın zamanda kullanılabilir bir snapshot üretmeyen yapılandırılmış bir job, recovery sistemi değildir.
Restore yetkisini belirleyin
Production restore işlemini kimin onaylayacağını ve restore sonrası doğrulamayı kimin gerçekleştireceğini belirleyin. Onay ile uygulamanın yürütülmesini ayırmak, aciliyet nedeniyle target ve snapshot doğrulamasının atlanma ihtimalini azaltır.
Doğrulanabilir bir deployment ile başlayın
İrreplaceable production verilerini saklamadan önce production dışı bir volume oluşturun, snapshot alın, bir test dosyasını değiştirin ve restore tatbikatını tamamlayın.
app.dockup.ai'de ücretsiz başlayın. Free plan aylık $0'dır, başlangıç kredisi olarak $10 içerir ve bir workspace, üç database ve üç deployment desteği sunar.
SSS
Dockup volume'u deployment sonrasında da korunur mu?
Evet. Service container'ları değiştirilirken volume kalıcı olmaya devam eder; bunun için uygulamanın yapılandırılmış mount path'i kullanmaya devam etmesi gerekir.
PostgreSQL için volume snapshot'ı doğru backup yöntemi midir?
Hayır. Bir database data directory'sinin çalışır durumdayken alınan snapshot'ı transaction-consistent olmayabilir. Managed database'ler için managed database backup sistemini tercih edin.
Bir volume snapshot'ı restore edildiğinde ne olur?
Mevcut volume içeriği seçilen snapshot ile değiştirilir ve container yeniden başlatılır. Bu nedenle işlem onaylanmalı ve doğrulanmalıdır.
Dockup volume snapshot'larını zamanlayabilir mi?
Evet. Volume schedule komutu, retention count ile günlük snapshot'ları destekler ve schedule açıkça devre dışı bırakılabilir.
Bir uygulamayı rollback etmek volume'unu da rollback eder mi?
Hayır. Application deployment history ile volume snapshot history birbirinden ayrıdır. Yalnızca recovery planı gerektiriyorsa ikisini birlikte koordine edin.