Ana içeriğe geç
GOOGLE WORKSPACE

Google Workspace Vault, Saklama ve Yedekleme Stratejisi

Vault retention ve hold davranışını operasyonel backupdan ayırın; silinme, erişim, lisans ve geri kazanım kapsamını test edin.

İçerik güncellemesi:

Mimari ve çalışma modeli

Google Vault bilgi yönetişimi ve eDiscovery kapsamında veriyi saklama, hold, arama ve export işlevleri sunar. Kullanıcının sildiği verinin belirli koşullarda korunması, tüm uygulamayı önceki durumuna tek adımda döndüren backup anlamına gelmez. Vault kapsamı hizmet ve nesne türüne göre değerlendirilir; export ile hedef uygulamaya restore ayrı işlemlerdir.

Retention kuralı saklama ve silme davranışını belirler; hold başka bir koruma amacı taşır ve normal silme kurallarını etkileyebilir. Süre başlangıcı, özel/varsayılan kural, nesne ve scope farkı sonucu değiştirir. Bir hold kaldırıldığında başka koruma yoksa veri silinme sürecine girebilir. Üretim verisi üzerinde kuralı deneme-yanılmayla değiştirmeyin.

Lisans ve hesap lifecycleı korumanın parçasıdır. Vault destekleyen lisansın kaldırılması veya hesabın silinmesi beklenmeyen veri etkisi yaratabilir. Ayrılan kullanıcı için askıya alma, desteklenen arşivleme/koruma seçenekleri ve veri devri güncel koşullara göre planlanır. Hukuki saklama kararını teknik ekibin varsayımıyla belirlemeyin; yetkili kurum sorumlusu kapsamı tanımlar.

Bağımsız backup için Gmail, Drive, shared drive, Calendar ve diğer nesnelerin içerik, metadata, izin ve sürüm kapsamı ayrı doğrulanır. Kimlik ve silme yetkisi üretimden ayrılır. RPO son geri gelen iş kaydıyla, RTO ilk kabul edilmiş işlemle ölçülür. Üçüncü taraf üründe başarılı job, tam izin veya uygulama restoreunu garanti etmez.

  1. 1Saklama ve hold kapsamı
  2. 2Bağımsız backup
  3. 3Export / restore ayrımı
  4. 4Veri ve erişim kabulü
Saklama, export ve operasyonel restore sonuçlarını ayrı kanıtlayın.

Tasarım parametreleri

Nesne kapsamı
Her hizmet için saklanan, export edilen ve geri getirilen nesneyi ayrı kaydedin.
Kural ve hold
Başlangıç zamanı, scope ve başka koruma koşullarını birlikte inceleyin.
Lisans ve hesap
Ayrılışta entitlement ve veri koruma bağımlılığını silmeden doğrulayın.
Operasyonel restore
İçerik yanında izin, link ve uygulama kullanılabilirliğini kontrol edin.

Hesap ve uygulama örneği

Bir test posta mesajı ve dosyası için farklı saklama politikalarının etkisini kontrollü kapsamda inceleyin. Kullanıcı görünümünde silme, Vault araması/exportu ve backup restoreunu ayrı kaydedin. Vaultta bulunabilen nesnenin hedef uygulamada hangi yöntemle geri getirildiğini gösterin; export dosyası tek başına restore kabulü değildir.

Örnek kurtarmada son kayıt 14:10, olay 14:20, ilk kabul edilen işlem 14:55 olsun. RPO 10 dakika, RTO 35 dakikadır. Bir dosyanın yalnız içeriği geri geldiyse paylaşım ve izin kontrolü tamamlanana kadar uygulama kabulü verilmez.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Vaultta var, kullanıcı geri açamıyorPreservation/export yolu operasyonel restore değildir.Hedef uygulamaya geri kazanım yöntemi ve izin kapsamını test edin.
Beklenen veri korunmadıScope, lisans veya retention başlangıcı farklı olabilir.Nesne türü, etkili kurallar ve hesap/lisans işlem kaydını inceleyin.
Backup restore oldu, paylaşım eksikÜrün grant/link kapsamını geri getirmiyor olabilir.İçerik, izin, sahiplik ve linki gerçek kullanıcıyla doğrulayın.

Kabul ve doğrulama kontrolleri

  1. Saklama, export ve operasyonel restore sonuçlarını ayrı kanıtlayın.
  2. Nesne kapsamını güncel resmî dokümanla eşleştirin.
  3. Lisans/hesap değişimini test verisiyle değerlendirin.
  4. Üretim kimliği olmadan kurtarma erişimini sınayın.
  5. Geri gelen içerik, izin ve linkleri doğrulayın.
  6. RPO/RTOyu gerçek kayıt ve işlem zamanıyla ölçün.

İlgili kavramlar

Saklama politikası ve kapasite

Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.

RPO ve gerçek veri kaybı penceresi

RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.

RTO ve uçtan uca kurtarma süresi

RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Bir testin kronometresini hangi olayda başlatıp bitirdiğinizi açıkça yazın. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.

Kimlik doğrulama ve oturum

Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.

Uygulama tutarlılığı

Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.

Sürüm ve destek yaşam döngüsü

Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.

Birincil teknik dokümantasyon

Hazırlama yöntemi

Doz Teknoloji Teknik Ekibi tarafından hazırlanan bu rehberde üreticilerin resmi dokümanları temel alınır. Örnek senaryolar ve hesaplar yöntemi açıklamak içindir; tamamlanmış müşteri testleri değildir. Uygulamadan önce sürüm, lisans, istemci desteği, güvenlik koşulları ve geri dönüş planını kendi ortamınızda doğrulayın. Seçim mevcut ürünlerinize ve iş yükünüze göre yapılır.

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!