Exchange Server Backup VS Journaling mimarisi yıllardır aynı cümlede birlikte geçen iki teknoloji olsa da çoğu IT yöneticisinin zihninde hâlâ büyük bir karışıklığa neden oluyor.
“Zaten düzenli yedek alıyorum, bu tüm e-postaları otomatik olarak kayıt altına alıyordur” düşüncesi, Exchange Server dünyasında en sık karşılaşılan teknik yanlışlardan biridir. Aslında her iki mekanizma tamamen farklı katmanlarda çalışır, tamamen farklı amaçlar taşır, farklı çıktı türleri üretir ve birbirinin yerine geçebilecek sistemler değildir. Aksine, kurumsal yapılarda birbirini tamamlayan iki ayrı güvenlik ve uyumluluk bileşeni olarak değerlendirilmelidir.
Bu nedenle bu makale,Exchange Server Backup VS Journaling mimarisi teknik olarak nerede konumlandığını, hangi gereksinimlere cevap verdiğini ve hangi problemlerin çözümü için uygun olmadığını net bir çerçevede ele alıyor. Hybrid yapılardaki davranış farkları, uyumluluk ve yasal kayıt zorunlulukları, performans etkileri, veri bütünlüğü açısından kritik noktalar ve Best Practice önerileri gerçek senaryolarla açıklanıyor.
Bu içerik, Exchange Server üzerinde veri koruma, hukuki kayıt yükümlülükleri ve mimari tasarım kararlarında doğru yaklaşımı belirlemek isteyen herkes için kapsamlı bir rehber niteliğinde olacaktır.
1. Temel Kavramlar, Backup ve Journaling Nedir?
Exchange Server Backup, EDB veritabanlarının, transaction log’ların ve kritik konfigürasyon bileşenlerinin anlık bir kopyasını alarak sistemin belirli bir zamandaki durumunu korumayı hedefler. Donanım arızaları, veri bozulmaları, kullanıcı hataları veya daha büyük çaplı felaket durumlarında tüm yapıyı güvenli bir şekilde geri döndürebilmek için tasarlanmış bir koruma katmanıdır.
Yani Backup, Exchange’in bütününü kapsayan geniş bir veri kurtarma mekanizmasıdır.
Exchange Server Journaling, Exchange’in Transport katmanında çalışır ve kurumdan geçen tüm e-posta trafiğinin birebir kopyasını gerçek zamanlı olarak belirlenmiş bir Journal hedefine iletir. Bu hedef genellikle Bir Mailbox Database, Bazen bir posta kutusu bazen de üçüncü taraf bir arşiv sistemi veya uyumluluk çözümüdür.
Journaling’in amacı veri kurtarmak değil; yasal kayıt oluşturmak, denetim süreçlerini desteklemek ve düzenleyici gereksinimleri karşılamaktır. Dolayısıyla Backup’ın zaman noktasında koruma sağladığı yerde, Journaling mesaj bazında kesintisiz bir kayıt zinciri oluşturur.
| Boyut | Exchange Backup | Exchange Journaling |
|---|---|---|
| Temel Amaç | Veritabanlarını ve sistem bileşenlerini yedekleyerek felaket durumunda geri yükleme imkânı sağlar. | E-posta trafiğinin kopyasını üreterek yasal kayıt, denetim ve uyumluluk gereksinimlerini karşılar. |
| Çalışma Katmanı | Storage / veritabanı katmanında çalışır (EDB, log, snapshot vb.). | Transport katmanında çalışır; mesaj akışı üzerinde kopya üretir. |
| Odak Noktası | Disaster Recovery, veri bütünlüğü, sistem sürekliliği. | Regülasyon, denetim, hukuki delil ve soruşturma süreçleri. |
Bu iki mekanizmanın nerede konumlandığını, neyi çözdüğünü ve neyi çözmediğini daha net görebilmek için bir sonraki bölümde yer alan karşılaştırma tablosu makalenin referans noktası niteliğindedir. Bu tablo, mimariyi doğru anlamak ve sonraki başlıklardaki detayları sağlam bir bağlama oturtmak için ideal bir başlangıç oluşturur.
2. Backup ve Journaling Kullanım Amacı
Birçok kurum hâlâ “Backup alıyorsak zaten tüm e-postalar güvence altındadır” varsayımıyla hareket eder ve bunun doğru olduğunu düşünür. Ancak Exchange Server yapısında Backup ve Journaling tamamen farklı mekanizmalardır; biri felaket kurtarma için çalışırken, diğeri yasal kayıt ve kanıt zinciri üretmek için tasarlanmıştır. Dolayısıyla bu iki sistemi aynı çerçevede değerlendirmek, hem operasyonel risklere hem de hukuki boşluklara yol açabilir.
Bu nedenle önce bu yanlış varsayımı masaya koyuyoruz ve ardından Backup ile Journaling’in gerçekte neyi çözdüğünü, neyi çözmediğini ve neden birbirinin alternatifi olamayacağını gösteren karşılaştırmayı paylaşıyoruz. Aşağıdaki tablo, doğru mimari tasarım için gerekli tüm ayrımı en sade ve profesyonel haliyle ortaya koymaktadır.
| Boyut | Backup Ne Yapar / Yapmaz? | Journaling Ne Yapar / Yapmaz? |
|---|---|---|
| Çözdüğü Sorun | ✔ Felaket durumunda veritabanlarının geri yüklenmesini sağlar. ✔ Donanım arızası, disk bozulması, veri korupsi gibi durumlarda sistemin önceki bir duruma alınmasına imkân verir. ✔ Yanlış konfigürasyon sonrası tüm veritabanını geri döndürmek için kullanılabilir. |
✔ Regülasyon için zorunlu olabilen e-posta kayıtlarını üretir. ✔ Tüm gelen/giden e-posta trafiğinden bağımsız bir kopya oluşturur. ✔ Denetim, iç soruşturma, hukuki inceleme ve eDiscovery süreçleri için güvenilir veri sağlar. |
| Çözmediği Sorun | ✘ Yasal kayıt mekanizması değildir. ✘ Kullanıcı bir e-postayı sildikten sonra, yeni backup alındığında eski backup’lar üzerine yazılabilir; bu nedenle “değişmez kayıt” sağlamaz. ✘ Mesajın kimler arasında, tam olarak hangi içerikle, hangi zamanda geçtiğine dair hukuki zincir garantisi vermez. |
✘ Felaket kurtarma aracı değildir. ✘ Mailbox bazlı full restore yapmaz. ✘ EDB dosyasını geri yüklemez, sistem arızasında tek başına veri kurtarma çözümü sunmaz. ✘ Exchange hizmetinin sürekliliğini backup gibi garanti etmez. |
ackup ve Journaling çoğu zaman aynı ekosistemin parçaları olsa da temelde birbirinden tamamen farklı amaçlara hizmet eder. Backup, Exchange’in teknik sürekliliğini korurken Journaling, hukuki uyumluluk ve denetim zincirini güvence altına alır. Bu nedenle kurumsal yapılarda bu iki mekanizmanın birbirinin yerine geçmesi mümkün değildir; aksine doğru mimari ancak ikisinin birlikte kullanılmasıyla oluşur.
Bu ayrımı net bir şekilde kavramak, sadece teknik operasyonların değil; KVKK, finans regülasyonları, iç denetim süreçleri ve eDiscovery gibi kritik uyumluluk başlıklarının doğru yönetilmesi için de zorunludur.
3. Backup ve Journaling Mimari Farklar
Backup ve Journaling’in birbirinden ne kadar farklı amaçlara hizmet ettiğini gösteren en güçlü alanlardan biri, mimari düzeydeki ayrışmadır. Exchange Server yapısında bu iki mekanizma tamamen farklı katmanlarda çalışır ve farklı veri türlerini işleyerek farklı hedeflere çıktı üretir. Bu nedenle iki teknolojiyi doğru konumlandırmak için önce mimari yaklaşımı netleştirmek gerekir.
Backup, Exchange’in depolama ve veritabanı katmanında yer alırken sistemin bütününe yönelik geniş bir koruma sağlar. Journaling ise Transport pipeline üzerinde çalışır ve yalnızca mesaj akışı boyunca oluşan iletişim kayıtlarını hedefler. Bu farklılıklar yalnızca işleyişi değil; performansı, gereksinimleri, regülasyon uyumluluğunu ve veri saklama stratejilerini de doğrudan etkiler.
Aşağıdaki tablo, Backup ile Journaling’in mimari yapıdaki temel farklarını sade ve profesyonel bir çerçevede göstermektedir.
| Mimari Boyut | Exchange Backup | Exchange Journaling |
|---|---|---|
| Çalışma Katmanı | Storage/veritabanı katmanında çalışır; EDB ve log dosyaları üzerinden işlem yapar. | Transport katmanında çalışır; mesaj akışı sırasında kopya üretir. |
| Veri Seviyesi | Veritabanının tamamını (tüm mailbox’lar + sistem verisi) snapshot veya stream olarak alır. | Tek tek e-posta mesajları için “journal report” üretir; alıcı, gönderici ve içerik bazlı kayıt oluşturur. |
| Hedef Konum | Backup repository, disk/tape, D2D, bulut backup ortamları. | Journal mailbox, 3rd party arşiv sistemi, WORM depolama veya uyumluluk platformu. |
Bu mimari ayrım açıkça gösteriyor ki Backup ve Journaling aynı soruna hizmet eden alternatif mekanizmalar değildir. Backup, veritabanı bütünlüğünü ve sistem sürekliliğini korurken; Journaling tek tek e-posta mesajlarının hukuki ve denetim amaçlı kaydını sağlar. Dolayısıyla biri felaket kurtarma sürecinin temeli iken, diğeri uyumluluk ve kanıt zinciri oluşturmanın vazgeçilmez bir parçasıdır.
Kurumlar için doğru Exchange mimarisini oluşturmanın yolu, bu iki yapının hangi katmanda çalıştığını ve hangi veri türünü ele aldığını doğru kavramaktan geçer. Makalenin sonraki bölümleri, hibrit yapılarda bu farkların nasıl sonuçlar doğurduğunu ve pratik best practice önerilerini içeren daha derinlemesine bir analiz sunacaktır.
4. Hybrid Ortamlarda Backup vs Journaling Davranışı
Office 365 Hybrid Exchange mimarileri, Backup ve Journaling mekanizmalarının birbirinden farklı davranışlarını en net şekilde ortaya çıkaran ortamlardır. Çünkü burada hem on-prem Exchange sunucuları hem de Exchange Online posta kutuları aynı yapı içinde yer alır ve her iki tarafın veri akışı, yedekleme senaryoları ve journaling gereksinimleri birbirinden tamamen farklıdır. Bu nedenle hibrit ortamlarda yanlış bir varsayım ya da eksik bir mimari, özellikle journaling tarafında geri dönüşü olmayan veri kayıplarına ya da uyumluluk açıklarına yol açabilir.
Office 365 Hybrid yapılarda backup işlemleri daha çok on-prem veritabanlarını kapsarken, journaling tamamen mail flow’un geçtiği rota, kullanılan Transport kuralları ve arşiv hedefinin konumu gibi faktörlere bağlıdır. Dolayısıyla, iki mekanizmanın hibrit mimaride nasıl çalıştığını anlamak, özellikle uyumluluk gereksinimleri bulunan kurumlar için kritik önem taşır.
Aşağıdaki tablo, on-prem mailbox’lardan Exchange Online tarafına kadar hibrit bir yapıda Backup ve Journaling’in farklı davranışlarını özet bir bakışla gösterir.
| Hybrid Boyut | Backup | Journaling |
|---|---|---|
| On-Prem Mailbox’lar | Klasik Exchange aware backup yazılımları ile on-prem EDB ve log’lar yedeklenir. | On-Prem Transport üzerindeki journaling kuralları ile tüm trafik için kopya üretilebilir. |
| Exchange Online Mailbox’lar | EXO için genellikle 3rd party Office 365 backup çözümleri devreye girer. | EXO, klasik anlamda “built-in journaling + local mailbox hedefi” sunmaz; genelde harici journaling hedefi (3rd party archive) zorunludur. |
| Mail Flow Yönlendirmesi | Mail flow’dan bağımsız; yedekleme, veritabanına yazıldıktan sonra gerçekleşir. | Mail flow’un hangi SMTP Gateway üzerinden geçtiği kritiktir; yanlış rotalama journaling kaybına yol açabilir. Hibrit yapılarda Journaling ihtiyacı Mailflow Transport Kuralları üzerinden çözülmektedir. |
Backup ve Journaling’in davranışı tek bir teknoloji mantığıyla açıklanamaz; her iki tarafın kendi işleyişi, veri katmanı ve rotalama senaryosu bağımsızdır. Bu nedenle hibrit Exchange mimarisinde hem backup çözümünün hem de journaling mimarisinin ayrı ayrı tasarlanması gerekir.
Özellikle journaling tarafında mail flow rotası, hedef arşiv sistemi ve Transport kurallarının doğru tanımlanması; uyumluluk açısından kesintisiz ve eksiksiz kayıt zinciri oluşturmanın temel şartıdır.
Bu farkları doğru anlamak, hibrit yapılarda veri güvenliği, felaket kurtarma stratejileri, KVKK/regülasyon uyumluluğu ve kurumsal denetim gereksinimleri açısından doğru tasarımı kurmanın en önemli adımlarından biridir.
5. Uyumluluk (Compliance) Perspektifi
Backup ve Journaling kavramlarını teknik açıdan ayırmak elbette önemlidir; ancak asıl kritik fark, uyumluluk ve yasal gerekliliklerin devreye girdiği noktada ortaya çıkar. Çünkü birçok organizasyon, e-posta trafiğini yalnızca operasyonel amaçlarla değil; denetim süreçleri, iç soruşturmalar, yasal yükümlülükler ve regülasyonların zorunlu kıldığı saklama politikaları doğrultusunda da yönetmek zorundadır. Bu nedenle “Exchange Backup bize yeter” yaklaşımı, uyumluluk dünyasında hem teknik hem de hukuki açıdan ciddi riskler doğurur.
Uyumluluk perspektifinde önemli olan yalnızca veriyi saklamak değil, bu verinin değişmez, manipüle edilemez, bağımsız, kesintisiz ve delil niteliği taşıyan bir kayıt olarak korunmasıdır. Backup mekanizması bunu sağlayacak şekilde tasarlanmamıştır. Journaling ise tam tersine, regülasyonların beklediği kanıt zincirini oluşturmak için üretilmiştir.
Aşağıdaki tablo, Backup ve Journaling’in uyumluluk dünyasındaki rollerini ve neden birbirinin yerine geçemeyeceklerini net bir şekilde göstermektedir.
| Uyumluluk Boyutu | Backup | Journaling |
|---|---|---|
| Yasal Kayıt | Yasal kayıt aracı olarak kabul edilmez; backup veri seti, son kullanıcı manipülasyonlarını içeriyor olabilir. | Yasal kayıt mekanizmasıdır; mesaj akışı sırasında bağımsız kopya üreterek delil niteliğinde veri sağlar. |
| Değişmezlik (Immutability) | Backup döngüsü (full/incremental) nedeniyle üzerine yazılabilir; immutable değildir. | WORM veya 3rd party archive ile immutable saklama mümkündür; regülasyonların istediği uzun süreli saklama sağlanabilir. |
| Regülasyon Uyumu (FINRA, SEC, KVKK vb.) | Tek başına genelde yeterli görülmez; resmi denetimlerde “uyum mekanizması” olarak kabul edilmez. | Çoğu regülasyon tarafından zorunlu veya şiddetle tavsiye edilir; denetim otoriteleri tarafından beklenen mekanizmadır. |
Exchange Server Backup, teknik olarak değerli bir veri koruma mekanizması olsa da uyumluluk tarafında tek başına hiçbir zaman yeterli değildir. Çünkü Backup, değişmezlik garantisi sunmaz, kullanıcı manipülasyonlarına karşı koruma sağlamaz ve çoğu regülasyonun “delil niteliği taşıyan kayıt” beklentilerini karşılamaz. Buna karşın Journaling, hem mesaj akışı sırasında bağımsız kopya üretmesi hem de WORM/3rd party arşiv çözümleriyle immutable saklama imkânı sunması sayesinde resmi denetimlerde kurumun en güçlü savunma mekanizmasıdır.
Uyumluluk gereksinimleri artan modern kurumlarda Backup ve Journaling artık yan yana değil, birbirini tamamlayan iki zorunlu bileşen olarak değerlendirilmelidir.
6. Performans ve Kapasite Etkileri
Exchange Server Backup ve Journaling’in mimari ve uyumluluk boyutları kadar önemli bir diğer başlık, sistem kaynaklarını nasıl etkiledikleridir. Özellikle yüksek hacimli e-posta trafiğine sahip kurumlarda, yanlış tasarlanmış bir backup stratejisi veya yetersiz kurgulanmış bir journaling mimarisi hem performans sorunlarına hem de kapasite yönetiminde ciddi darboğazlara yol açabilir. Bu nedenle her iki mekanizmanın operasyonel yükü, sunucu üzerindeki etkisi ve depolama ihtiyacı ayrı ayrı ele alınmalıdır.
Backup işlemleri genellikle veritabanı boyutu, disk I/O kapasitesi ve network trafiğiyle doğrudan ilişkilidir. Büyük EDB dosyalarında uzun süren backup pencereleri kaçınılmaz hâle gelebilir. Journaling tarafında ise her mesaj için Transport katmanında ek işlem yapılır ve bu durum yoğun mail akışına sahip yapılarda CPU, queue ve arşiv sistemi üzerindeki yükü artırır.
Aşağıdaki tablo, Backup ile Journaling’in kurumsal Exchange yapılarda performans ve kapasite açısından nasıl farklı etkiler yarattığını net bir çerçevede özetlemektedir.
| Boyut | Backup Etkisi | Journaling Etkisi |
|---|---|---|
| Sunucu Performansı | Backup penceresi sırasında disk I/O ve network trafiği artar; özellikle büyük EDB’lerde yedek süresi uzayabilir. | Transport katmanında her mesaj için ek işlem yapılır; yüksek mail trafiğinde Transport CPU ve queue’lar etkilenebilir. |
| Depolama İhtiyacı | Backup retention süresine göre TB’larca depolama gerekebilir; full + incremental stratejisi doğru tasarlanmalıdır. | Journal hedefinde, tüm mail trafiğinin ikinci bir kopyası tutulur; arşiv sistemi için ayrı kapasite planlaması yapılmalıdır. |
| Operasyonel Yük | Backup job’larının izlenmesi, hatalı job’ların yeniden çalıştırılması, restore testleri vs. düzenli operasyon gerektirir. | Journal queue’larının izlenmesi, hedef sistem bağlantılarının takibi ve arşiv kapasite yönetimi gerektirir. |
Tabloda görüldüğü gibi Exchange Server Backup ve Journaling, performans ve operasyonel yük açısından birbirinden ayrı değerlendirilmesi gereken iki süreçtir. Backup; disk, network ve veritabanı boyutuna bağlı olarak sistem kaynaklarını yoğun şekilde kullanırken, Journaling özellikle Transport katmanında CPU ve queue yükü oluşturur ve arşiv sisteminin kapasitesini doğrudan etkiler. Bu nedenle her iki mekanizmanın da ölçekleme stratejileri, saklama politikaları ve hedef sistemleri doğru planlanmalıdır.
Kurumların sağlıklı bir Exchange ortamı işletebilmesi için hem backup penceresinin optimize edilmesi hem de journaling sürecinin arşiv kapasitesiyle uyumlu şekilde tasarlanması kritik öneme sahiptir. Takip eden bölümlerde best practice önerileriyle ideal tasarımın nasıl olması gerektiğini daha detaylı ele alarak, sürdürülebilir ve denetim dostu bir Exchange mimarisinin adımlarını tamamlayacağız.
7. Exchange Server Backup + Journaling Birlikte Yapılandırma
Bu noktaya kadar Backup ve Journaling’in teknik, mimari, uyumluluk ve performans boyutlarını ayrı ayrı ele aldık. Artık bu iki mekanizmanın nasıl birlikte, doğru ve sürdürülebilir bir şekilde kullanılacağı sorusuna odaklanma zamanı. Çünkü kurumsal Exchange ortamlarında asıl değer, tek bir teknolojiyi güçlü kullanmaktan değil; Backup ve Journaling’i birbirini tamamlayan bir mimari olarak konumlandırmaktan doğar.
Yanlış tasarlanmış bir backup stratejisi felaket anında geri dönüş süresini uzatırken, eksik veya hatalı bir journaling kurgusu denetim ve regülasyon süreçlerinde telafisi olmayan riskler yaratabilir. Bu nedenle Best Practice yaklaşımı, yalnızca teknik gereksinimleri değil; operasyonel sürdürülebilirliği, hukuki beklentileri ve denetim senaryolarını da kapsamalıdır.
Aşağıdaki tablo, kurumsal yapılarda Backup ve Journaling’in birlikte nasıl konumlandırılması gerektiğini, pratik ve uygulanabilir önerilerle özetlemektedir.
| Alan | Önerilen Yaklaşım |
|---|---|
| Backup Stratejisi | • Düzenli full + incremental backup planı oluşturun. • Restore testlerini periyodik olarak yapın (sadece backup almak yetmez). • DAG, log truncation ve storage tasarımını backup penceresine göre optimize edin. |
| Journaling Tasarımı | • Journal hedefi olarak normal kullanıcı mailbox’ı kullanmayın. • Mümkünse WORM özellikli 3rd party arşiv sistemleri tercih edin. • Hybrid yapılarda mail flow’un mutlaka journaling’i tetikleyecek rotadan geçtiğini doğrulayın. |
| Uyumluluk ve Denetim | • Regülasyon beklentilerini (KVKK, sektör regülasyonları vb.) hukuk ve uyum ekipleriyle birlikte netleştirin. • Backup’ı değil, journaling + arşiv sistemini “denetim kaynağı” olarak konumlandırın. • Denetim senaryolarını (ör. belirli kullanıcılar, departmanlar) için targetted journaling kullanmayı değerlendirin. |
| Dökümantasyon | • Backup ve journaling mimarisini diyagramlarla dokümante edin. • Kim neye erişir, hangi veriye hangi yolla ulaşıyor, net tanımlayın. • Olası bir denetimde tek PDF ile tüm yapıyı açıklayabilir durumda olun. |
Bu Best Practice önerileri, Backup ve Journaling’in birbirinin alternatifi değil, tamamlayıcısı olduğunu net biçimde ortaya koymaktadır. Backup, sistem sürekliliği ve felaket kurtarma için vazgeçilmezken, Journaling, uyumluluk, denetim ve hukuki güvence tarafında kurumun sigortasıdır. Bu iki yaklaşımın birlikte ve bilinçli şekilde tasarlanması, Exchange altyapısının yalnızca teknik olarak değil, kurumsal risk yönetimi açısından da sağlam temellere oturmasını sağlar.
Doğru dokümantasyon, düzenli testler ve regülasyonlara uyumlu bir mimari sayesinde kurumlar hem operasyonel esnekliğe hem de denetimlerde güçlü bir savunma hattına sahip olur. Bu makalenin son bölümünde, tüm bu bilgileri tek bir çerçevede toplayarak “doğru Exchange mimarisi”nin nasıl olması gerektiğini özetleyeceğiz.
8. Sonuç, Backup ve Journaling Aynı Şeyi Yapmaz
Makalenin en başında sorduğumuz soruya geri dönelim: “Yedek alıyorsam zaten tüm e-postalar kayıt altındadır.” Bu ifade, Exchange Server dünyasında en yaygın ama aynı zamanda en tehlikeli yanlış kabullerden biridir. Cevap nettir: Hayır, doğru değildir.
Journaling; yasal kayıt oluşturmak, regülasyonlara uyum sağlamak ve denetim ile soruşturma süreçlerinde delil niteliği taşıyan veri üretmek için tasarlanmış vazgeçilmez bir mekanizmadır. Transport katmanında çalışması sayesinde mesaj akışı sırasında bağımsız kopya üretir ve özellikle hibrit yapılarda doğru mail-flow yönlendirmesi yapılmadığında ciddi uyumluluk kayıpları yaşanmasına neden olabilir. Bu nedenle Journaling, teknik bir tercih değil, çoğu kurum için hukuki bir zorunluluktur.
Backup ise tamamen farklı bir amaca hizmet eder. Sistem sürekliliğini sağlamak, veri kaybı sonrasında geri yükleme yapabilmek ve felaket kurtarma senaryolarında Exchange ortamını yeniden ayağa kaldırmak için kritik bir sigorta mekanizmasıdır. Ancak backup verileri değiştirilebilir, üzerine yazılabilir ve kullanıcı aksiyonlarını içerebilir; bu nedenle hukuki anlamda “değişmez kayıt” yerine geçmez.
Bu makalede Backup ve Journaling’in nerede çalıştığını, hangi sorunları çözdüğünü ve hangi sorunları çözmediğini, hibrit ortamlardaki davranışlarını, uyumluluk ve performans boyutlarını ve en doğru best practice yaklaşımlarını karşılaştırmalı, tablo odaklı ve teknik bir modelle ortaya koyduk. Ama tüm bu detayların ötesinde çıkarılacak tek bir ana sonuç vardır.
Kurumsal Exchange mimarisinde en doğru yaklaşım, “Backup + Journaling kombinasyonu”dur. Backup sistemi ayağa kaldırır. Journaling gerçeği ispat eder. Biri olmadan diğeri, ya teknik tarafta ya da hukuki tarafta mutlaka bir boşluk bırakır.
Bu ayrımı net biçimde yapan kurumlar, yalnızca sistemlerini değil; risklerini, denetim süreçlerini ve kurumsal güvenilirliklerini de doğru şekilde yönetmiş olurlar.
