Microsoft 365 Yedekleme: Exchange, OneDrive ve SharePoint Verisi

“Microsoft 365’e geçtik, artık yedeğe gerek yok.” Bu cümleyi duyduğumuz toplantıların çoğu, birkaç ay sonra silinmiş bir proje klasörünü arayan telefonla devam eder. Microsoft hizmetin erişilebilirliğini ve altyapının dayanıklılığını üstlenir. Kullanıcı hatası, kötü niyetli silme, fidye yazılımı ya da hatalı bir senkronizasyonla kaybolan veriyi istediğiniz tarihe döndürmek ise sizin işinizdir. Aşağıda yerleşik saklama özelliklerinin gerçek yedekle farkını, yedek gerektiren senaryoları, araç seçim kriterlerini ve tipik geri yükleme işlemlerini anlatıyoruz.

Paylaşılan sorumluluk modeli

SaaS modelinde sorumluluk katmanlara bölünür. Microsoft fiziksel veri merkezini, donanımı, uygulama altyapısını ve veri merkezleri arası çoğaltmayı yönetir. Bu çoğaltma bir veri merkezinin kaybına karşı hizmeti korur; ama sizin tarafınızda yapılan bir silme veya şifreleme de aynı hızla tüm kopyalara yansır. Çoğaltma yedek değildir. Müşteri tarafında kalanlar:

• Verinin kendisi ve kimin neyi silebileceği (yetkilendirme).
• Kimlik güvenliği: ele geçirilmiş bir hesabın yaptığı silme, Microsoft açısından meşru bir işlemdir.
• Saklama süreleri, yasal saklama gereksinimleri ve ayrılan çalışanların verisi.
• Belirli bir tarihe geri dönebilecek bağımsız kopya.

Hizmet sürekliliği, yani Microsoft 365 kesintilerinde iş akışının nasıl sürdürüleceği ayrı bir konudur ve Microsoft 365 ve bulut altyapısında süreklilik yazısında anlatılıyor. Burada konu verinin bağımsız korunması.

Yerleşik saklama özellikleri ve sınırları

Microsoft 365, silinen öğeleri belirli bir süre geri getirmek için birkaç mekanizma sunar. İşe yararlar, ama yedek değildirler: aynı hizmet içinde, aynı yönetici hesaplarının erişiminde ve sınırlı süreyle tutulurlar.

Varsayılan değerler zamanla değişebilir; kendi tenant’ınızdaki geçerli ayarları Microsoft belgelerinden ve yönetim merkezinden doğrulayın. Yeni tenant’larda ilk yaptığımız ayarlardan biri, Recoverable Items süresini Exchange Online PowerShell ile 30 güne çekmektir:

Connect-ExchangeOnline
Get-Mailbox -ResultSize Unlimited | Set-Mailbox -RetainDeletedItemsFor 30
Get-Mailbox -SoftDeletedMailbox | Select DisplayName, WhenSoftDeleted

En çok yanlış anlaşılan özellik saklama ilkeleridir (retention policy). İçeriği gizli bir alanda koruyarak eDiscovery ile bulunabilir kılar; ama bir kullanıcının 3.000 dosyalık klasörünü, orijinal klasör yapısı ve izinleriyle belirli bir tarihe döndürmek için uygun bir araç değildir. Uyum aracıdır, geri yükleme aracı değil.

Yedek gerektiren senaryolar

• Fidye yazılımı ve toplu şifreleme: OneDrive senkronizasyon istemcisi, şifrelenmiş dosyaları buluta yükler. 30 günlük geri yükleme penceresi içinde fark edilirse yerleşik araçla dönülebilir. Fark edilme gecikirse veya sürümler de etkilendiyse bağımsız kopya gerekir.
• Kötü niyetli veya ele geçirilmiş yönetici: Yönetici yetkisiyle kalıcı silme, geri dönüşüm kutusunu boşaltma ve saklama ayarlarını değiştirme mümkündür. Saldırgan önce bunları yapar.
• Ayrılan çalışan: Lisansı kaldırılan kullanıcının posta kutusu ve OneDrive’ı süre sonunda silinir. Aylar sonra bir hukuki ihtiyaç doğduğunda veri kalmamış olabilir.
• Uzun süre fark edilmeyen silme: Bir proje sitesinden silinen klasör altı ay sonra aranırsa geri dönüşüm kutusu süresi çoktan dolmuştur.
• Hatalı toplu işlem ve göç: Yanlış bir PowerShell betiği, senkronizasyon aracı veya tenant-to-tenant geçiş sırasında yapılan hata çok sayıda nesneyi etkileyebilir.

Yedekleme aracı seçim kriterleri

İki ana yol var: Microsoft’un kendi ürünü Microsoft 365 Backup ve üçüncü taraf yedekleme ürünleri (Veeam Backup for Microsoft 365 ve benzerleri). Broşürü değil, şu kriterleri karşılaştırın:

Satın almadan önce şu soruları da sorun:

• API ve kısıtlama: Araç Microsoft Graph veya Microsoft’un yedekleme için sunduğu API’leri kullanıyor mu? Exchange Web Services (EWS) için Microsoft’un açıkladığı kullanımdan kaldırma takvimine uyumlu mu? Büyük tenant’larda ilk tam yedek, kısıtlamalar yüzünden günler sürebilir; bunu takvime koyun.
• Kimlik izolasyonu: Yedek konsolu ve depo, Microsoft 365 yönetici hesaplarından bağımsız kimlik bilgileriyle mi korunuyor? Değiştirilemez (immutable) depolama destekleniyor mu?
• Veri yerleşimi: Yedeklerin tutulduğu bölge, kişisel veri işleme yükümlülükleriyle uyumlu mu?
• Granülerlik: Tek e-posta, takvim öğesi, dosya sürümü ve izinlerle birlikte site geri yükleme yapılabiliyor mu? Farklı konuma veya PST/dosya olarak dışa aktarma var mı?
• Yedekleme sıklığı: Günde kaç kez kurtarma noktası oluşturulabiliyor? Bu doğrudan RPO’yu belirler.

Microsoft 365 Backup’ın desteklediği iş yükleri ve saklama süreleri değişmeye devam ediyor; kapsamı Microsoft’un güncel belgelerinden doğrulayın.

Kapsam: Exchange, OneDrive, SharePoint, Teams

Exchange Online: Kullanıcı ve paylaşılan posta kutuları, arşiv posta kutuları, takvim ve kişiler. Paylaşılan posta kutuları lisanssız olabildiği için bazı araçlarda kapsam dışında kalır. Sahada en sık atlanan kalem budur; işin içinde olduğunu tek tek kontrol edin.

OneDrive: Kullanıcının kişisel dosyaları. Şirket içi sunucu altyapısından taşınan departman verisi yanlışlıkla OneDrive’larda kalmışsa, çalışan ayrıldığında bu veri risk altına girer; göç planlamasında bu konu dosya sunucusundan SharePoint ve OneDrive’a göç yazısında ele alınıyor.

SharePoint: Site koleksiyonları, belge kitaplıkları, listeler ve izinler. Microsoft 365 grubu veya Teams ile oluşturulan her ekip arkasında bir SharePoint sitesi barındırır. Yedek işi siteleri tek tek seçerek kurulduysa, geçen ay açılan ekip yedekte yoktur. Kapsamı otomatik dahil etme kuralıyla tanımlayın.

Teams: Ekip dosyaları SharePoint’te, kanal ve sohbet mesajları ise Exchange tabanlı depolamada tutulur. Teams’in “tam” yedeği bu yüzden birden çok kaynaktan oluşur. Mesaj yedeklemesi bazı ürünlerde Microsoft’un ayrıca ücretlendirdiği korumalı API’leri gerektirir. Kanal mesajlarının, özel ve paylaşılan kanalların gerçekten kapsandığını demo ortamında değil, kendi tenant’ınızda geri yükleyerek görün.

Geri yükleme senaryoları

Tek e-posta veya klasör

Öğe Recoverable Items süresi içindeyse (varsayılan 14 gün, en fazla 30 gün) Outlook’taki “Silinmiş öğeleri kurtar” yeterlidir. Pencere dolmuşsa yedek aracından öğe düzeyinde geri yükleme yapılır. Orijinal posta kutusuna ayrı bir klasör olarak geri yükleyin; mevcut veriyle karışmaz, kullanıcı neyin geri geldiğini görür.

Tüm site veya kitaplık

Fidye veya hatalı toplu işlemde ilk iş etki zamanını bulmaktır; denetim günlüğünde toplu değişikliğin başladığı dakikaya bakın. Olay 30 gün içindeyse SharePoint’in kitaplığı geri yükleme özelliği hızlı bir seçenektir; değilse yedekten olaydan önceki kurtarma noktası seçilir. Önce zaman, sonra geri yükleme. Silinmiş bir site koleksiyonu saklama süresi içindeyse SharePoint yönetim merkezinden veya Restore-SPODeletedSite cmdlet’iyle geri getirilebilir.

Ayrılan çalışan

Verinin akıbetini lisans kaldırılmadan önce kararlaştırın: posta kutusunu paylaşılan posta kutusuna dönüştürmek, saklama ilkesiyle inaktif posta kutusu olarak korumak veya yalnızca yedekte tutmak. Lisans 30 gün önce kaldırıldıysa vakit dar. Silinmiş bir posta kutusundan içeriği başka bir posta kutusuna aktarmak için Exchange Online’da şu yöntem kullanılır:

$silinen = Get-Mailbox -SoftDeletedMailbox -Identity "ayse.yilmaz@firma.com.tr"
New-MailboxRestoreRequest -SourceMailbox $silinen.ExchangeGuid `
  -TargetMailbox "arsiv-ayrilanlar@firma.com.tr" `
  -TargetRootFolder "Ayse Yilmaz" -AllowLegacyDNMismatch

Uygulama kontrol listesi

• Yedeklenecek iş yükleri ve hariç tutulacak nesneler yazılı olarak belirlendi mi?
• Yeni kullanıcı, paylaşılan posta kutusu, grup ve siteler otomatik kapsama giriyor mu?
• Yedek deposu Microsoft 365 yönetici kimliklerinden bağımsız korunuyor mu?
• Saklama süresi kurumsal saklama politikasıyla uyumlu mu?
• İlk tam yedek tamamlandı ve sonraki artımlı yedeklerin süresi izleniyor mu?
• Her çeyrekte tek öğe, tek kullanıcı ve bir site geri yükleme testi yapılıyor mu?
• Ayrılan çalışan süreci yedek ve lisans adımlarıyla birlikte dokümante edildi mi?

Kopya sayısı ve test disiplini açısından 3-2-1-1-0 yedekleme kuralı Microsoft 365 verisi için de geçerlidir. Tenant yapılandırmasını ve yedek kurgusunu nasıl ele aldığımızı Microsoft 365 ve bulut hizmetleri ile yedekleme ve felaket kurtarma sayfalarımızda bulabilirsiniz. Microsoft’un kendi çözümünün kapsamı için Microsoft 365 Backup genel bakış belgesi başlangıç noktasıdır.

Sık sorulan sorular

Microsoft 365 verilerimi zaten yedekliyor mu?

Microsoft altyapıyı çoğaltarak hizmetin erişilebilirliğini korur ve silinen öğeleri sınırlı süre geri getirme imkânı sunar. Belirli bir tarihe geri dönülebilen, yönetici hesaplarından bağımsız bir yedek ise müşterinin sorumluluğundadır.

Geri dönüşüm kutusu ve saklama ilkeleri yedeğin yerini tutar mı?

Tutmaz. Geri dönüşüm kutusu ve Recoverable Items süreyle sınırlıdır; saklama ilkeleri uyum amaçlıdır ve klasör yapısı ile izinlerle toplu geri yükleme için tasarlanmamıştır. Hepsi aynı hizmet ve aynı yönetici erişimi içinde kalır.

Microsoft 365 Backup mı üçüncü taraf çözüm mü seçilmeli?

Microsoft 365 Backup hizmet sınırı içinde hızlı büyük ölçekli geri yükleme sunar. Üçüncü taraf çözümler veriyi farklı bir ortamda ve bağımsız kimlikle tutar. Saklama yeri, kapsam, geri yükleme hızı ve maliyeti birlikte değerlendirin.

Teams yedeklemesinde nelere bakılmalı?

Teams verisi birden çok yerde durur: dosyalar SharePoint’te, mesajlar Exchange tabanlı depolamada. Aracın kanal mesajlarını, özel ve paylaşılan kanalları gerçekten kapsadığını ve gerekiyorsa ücretli API’leri kullandığını kendi tenant’ınızda test edin.