Bu Konu Neden Önemli?
Exchange Online Archive, kullanıcı posta kutularında uzun süreli e-posta saklama ve arşivleme için ayrı archive mailbox kapasitesi sağlayabilen Microsoft 365 özelliğidir.
Karar Verirken Kontrol Edilecek Noktalar
Lisans gereksinimini kullanıcı bazında doğrulayın.
Retention ile archive mailbox kavramlarını ayırın.
Auto-expanding archive davranışını planlayın.
Kullanıcı erişim deneyimini pilotla doğrulayın.
Mimari ve çalışma modeli
Archive mailbox, ana posta kutusundan ayrı arşiv alanıdır; bağımsız backup veya bütün silinmeleri geri alma garantisi değildir. Mesaj taşıma politikası, saklama/silme politikası ve hold farklı görevler taşır. Güncel lisans ve archive özellikleri kullanıcı bazında doğrulanmalıdır. Arşive taşıma ile kullanıcının aramada bulabilmesi ayrı testlerdir.
- 1Ana mailbox
- 2Taşıma/retention politikası
- 3Archive mailbox
- 4Arama ve kurtarma testi
Tasarım parametreleri
- Arşive taşıma ve silme
- MRM arşiv politikası ile Purview saklama/hukuki koruma davranışını ayırın; arşiv bağımsız backup değildir.
- Lisans ve kullanıcı erişimi
- Arşiv kapasitesi, büyüme ve istemci desteğini güncel plana göre doğrulayın.
- Kimlik ve tenant sınırı
- Kullanıcı, misafir, yönetici ve uygulama kimliklerini ayırın. Tenant politikaları ile tek kaynağın izinleri aynı kapsam değildir.
- Veri sahipliği ve yaşam döngüsü
- Verinin sahibi, saklama süresi, silinme yolu ve geri kazanım yöntemi belirlenmelidir. Senkronizasyon ile yedeklemeyi ayırın.
- Lisans ve özellik kapsamı
- Kullanıcı rolü, cihaz, tenant ve gerekli özellik üzerinden lisans doğrulayın. Güncel paket adını geçmiş bilgiyle varsaymayın.
- Bağlantı ve maliyet
- İnternet, kimlik servisi, veri çıkışı, depolama ve işletim giderini birlikte değerlendirin. Bütçe alarmının harcamayı otomatik durdurduğunu varsaymayın.
Hesap ve uygulama örneği
Örnek pilotta belirli yaştaki sentetik mesajları arşive taşıyın; ana kutu ve arşivde aramayı test edin. Erişim yetkisi, mobil/masaüstü istemci ve yanlış silme kurtarmasını ayrı kaydedin. Arşiv etkinleşmesi kullanıcının bütün veri koruma gereksinimini otomatik karşılamaz.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Politika var, posta taşınmıyor | Etiket kapsamı, öğe yaşı veya işleme süreci etkili olabilir. | Örnek öğenin etiketi ve arşiv etkinliğini politika kaydıyla karşılaştırın. |
| Bazı kullanıcılar erişemiyor | Lisans, grup, cihaz durumu veya erişim politikası farklı olabilir. | Etkilenen ve çalışan kullanıcıların karar kayıtlarını karşılaştırın. |
| Silinen veri geri getirilemiyor | Saklama ve kurtarma kapsamı beklenenden farklı olabilir. | Nesne türü, silinme zamanı ve resmî kurtarma koşullarını doğrulayın. |
| Maliyet beklenenden yüksek | Kaynak boyutu, veri çıkışı, saklama veya taahhüt kullanımı farklı olabilir. | Kaynak ve hizmet bazında gerçekleşeni tahminle eşleştirin. |
Kabul ve doğrulama kontrolleri
- Taşıma, saklama ve geri kazanımı ayrı mekanizmalar olarak doğrulayın.
- Kullanıcı, misafir ve yönetici senaryolarını ayrı test edin.
- Kayıp cihaz ve iptal edilen erişim davranışını doğrulayın.
- Bir test nesnesini silip tanımlı yöntemle geri kazanın.
- Gerekli özellik için güncel lisans kapsamını belgeleyin.
- Günlükleri kimlik ve kaynak açısından uçtan uca eşleştirin.
İ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.
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.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
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.
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayı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. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun