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.
- 1Saklama ve hold kapsamı
- 2Bağımsız backup
- 3Export / restore ayrımı
- 4Veri ve erişim kabulü
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
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Vaultta var, kullanıcı geri açamıyor | Preservation/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
- Saklama, export ve operasyonel restore sonuçlarını ayrı kanıtlayın.
- Nesne kapsamını güncel resmî dokümanla eşleştirin.
- Lisans/hesap değişimini test verisiyle değerlendirin.
- Üretim kimliği olmadan kurtarma erişimini sınayın.
- Geri gelen içerik, izin ve linkleri doğrulayın.
- 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.
İlgili işbirliği rehberleri
Google Workspace Kurulum, Lisans ve Kullanıcı Yönetimi
Alan adı, kullanıcı, organizasyon birimi, grup, lisans ve çalışan yaşam döngüsü için kontrollü Workspace kurulum rehberi.
Rehberi inceleGoogle Workspace Gmail Geçişi: DNS, SPF, DKIM ve DMARC
Posta envanteri, migration kapsamı, MX değişimi, gönderici doğrulama ve delta kontrolüyle Gmail geçişini planlayın.
Rehberi inceleGoogle Drive ve Shared Drives: Sahiplik, Paylaşım ve Yetki Tasarımı
My Drive ve shared drive ayrımı; ekip sahipliği, dış paylaşım, grup erişimi, senkronizasyon ve çalışan ayrılışı kontrolleri.
Rehberi inceleGoogle Workspace Güvenliği: MFA, Cihaz, OAuth ve Audit
2-Step Verification, passkey, cihaz koşulları, uygulama izinleri ve olay kayıtları için katmanlı güvenlik rehberi.
Rehberi inceleGoogle Workspace ve Microsoft 365 (Office 365) Karşılaştırması
E-posta, belgeler, dosya paylaşımı, güvenlik, cihaz yönetimi, saklama ve toplam maliyet için ihtiyaç temelli karşılaştırma.
Rehberi inceleBilgi Merkezi’ndeki tüm rehberler
Platform seçimini mevcut ürünleriniz, iş yükünüz ve işletim ihtiyaçlarınızla birlikte değerlendiriyoruz.