Backup başarılı mesajı neden yeterli değildir?
Bir backup job'ının başarılı tamamlanması dosyanın eksiksiz, erişilebilir ve geri yüklenebilir olduğunu tek başına kanıtlamaz.
GitLab verisi farklı depolama katmanlarında bulunabilir. Backup kapsamı ile gerçek mimari karşılaştırılmalıdır.
- Repository ve veritabanı
- LFS, artifact, upload ve package verileri
- Container Registry
- Object storage üzerindeki içerikler
- GitLab yapılandırması ve secret dosyaları
- Harici PostgreSQL veya diğer bağımlılıklar
Salt okunur envanter kontrolleri
Dosya konumlarını, kapasiteyi ve mevcut zamanlanmış işleri değiştirmeden kaydedin. Gerçek secret değerlerini rapora eklemeyin.
sudo gitlab-rake gitlab:env:info
sudo du -sh /var/opt/gitlab/backups 2>/dev/null
sudo df -h
sudo gitlab-ctl status- GitLab sürümü ve Edition
- Son başarılı yedeğin zamanı ve büyüklüğü
- Yedeğin tutulduğu disk veya uzak hedef
- Kaynak veriyle yedek boyutu arasındaki beklenmeyen fark
- Yedek sırasında başarısız veya durdurulmuş bileşenler
Secret ve konfigürasyon ayrı değerlendirilmelidir
Uygulama verisi geri yüklense bile şifreleme anahtarları ve yapılandırma eksikse bazı veriler çözülemeyebilir veya servisler eski davranışıyla başlayamaz.
Secret dosyaları yedek arşiviyle aynı yerde ve korumasız tutulmamalı; erişim, şifreleme ve saklama politikası ayrıca belirlenmelidir.
- gitlab-secrets ve ana yapılandırma
- TLS private key ve kurum içi CA
- Object storage ve SMTP erişimleri
- LDAP/SAML/OAuth bilgileri
- Runner ve deployment secret bağımlılıkları
RPO ve RTO iş ihtiyacından türetilmelidir
RPO kabul edilebilir veri kaybı aralığını, RTO ise hizmetin ne kadar sürede geri dönmesi gerektiğini tanımlar.
Günlük yedek her işletme için yeterli değildir; veri değişim hızı, yedek süresi, aktarım bant genişliği ve restore süresi ölçülmelidir.
- Son 24 saatte oluşan repository ve issue değişiklikleri
- Registry ve artifact üretim hacmi
- Yedeğin başka hata alanına kopyalanma süresi
- Temiz altyapının hazırlanma süresi
- Kullanıcı ve pipeline kabul testleri
Restore provası production üzerinde yapılmamalıdır
Geri yükleme prosedürü izole bir ortamda, erişim ve dış entegrasyonlar sınırlandırılarak doğrulanmalıdır.
Restore işlemi mevcut veriyi değiştirebileceği için burada kopyalanabilir uygulama komutları vermiyoruz. Sürüm eşleşmesi, hedef kapasite ve kabul listesi prova öncesinde hazırlanmalıdır.
- Production'a e-posta veya webhook göndermeyen izole ağ
- Kaynakla uyumlu GitLab sürümü
- Yeterli disk, inode ve restore süresi
- Temsilî proje ve kullanıcı testleri
- Sonuçları ve süreleri içeren prova raporu
Atlas Infrastructure bu çalışmayı nasıl yürütür?
Mevcut backup kapsamını mimariyle karşılaştırır, eksik veri sınıflarını belirler ve iş hedeflerine uygun saklama yaklaşımı tasarlarız.
Ardından izole restore provası, doğrulama listesi, ölçülen RPO/RTO ve olay anında uygulanacak sorumluluk planını dokümante ederiz.
GitLab hakkında sık sorulanlar
GitLab backup Container Registry verisini her zaman içerir mi?
Depolama mimarisine ve yapılandırmaya bağlıdır. Registry ve object storage kapsamı ayrıca doğrulanmalıdır.
GitLab yedeği farklı sürüme geri yüklenebilir mi?
Restore genellikle belirli sürüm ve Edition uyumluluğu gerektirir. Hedef sürüm rastgele seçilmemeli, desteklenen yükseltme yolu ayrıca planlanmalıdır.
Yedek dosyasını aynı sunucuda tutmak yeterli mi?
Hayır. Aynı disk, sunucu veya hata alanındaki yedek; disk arızası, fidye yazılımı veya erişim kaybında birlikte etkilenebilir.