Saat 09.15’te muhasebe ekibi ERP’ye bağlanamıyor. Sunucuya erişim yok, şubeler belge kesemiyor ve son yedeğin nerede olduğu soruluyor. Böyle bir anda ihtiyaç duyulan şey, hangi hizmetin hangi sırayla ve kimin sorumluluğunda geri getirileceğinin bilinmesidir.
Uzak erişimde iş sürekliliği, kullanıcıların kritik uygulamalarına kesinti sonrasında kontrollü biçimde yeniden ulaşabilmesini planlamaktır. Bu rehber; Windows üzerinde ERP veya muhasebe uygulaması yayınlayan işletmeler için kurtarma hedeflerini, yedek kapsamını ve doğrulama adımlarını bir araya getirir. Aşağıdaki senaryolar ve zaman değerleri örnektir; kurumunuzun iş ihtiyaçlarına göre uyarlanmalıdır.
1. RTO ve RPO’yu iş birimiyle birlikte belirleyin
RTO (Recovery Time Objective), kesinti sonrasında işin yeniden başlayabilmesi için kabul edilen en uzun süredir. RPO (Recovery Point Objective) ise kabul edilebilir veri kaybının zaman karşılığıdır. Microsoft’un iş sürekliliği rehberi, bu iki hedefin teknik ve iş ekipleri tarafından birlikte değerlendirilmesini önerir. [1]
Örneğin bir muhasebe ekibi, ERP için 90 dakikalık RTO ve 15 dakikalık RPO hedefleyebilir. Saat 14.00’te başlayan kesintide işin en geç 15.30’da yeniden yürütülmesi, veri tarafında ise 13.45 sonrasındaki işlemlerden fazlasının kaybedilmemesi hedeflenir. Bu değerler ürün garantisi değildir; tasarım ve test için başlangıç koşullarıdır.
RTO yalnızca sanal makinenin açılma süresi olarak ölçülmemelidir. Arızanın fark edilmesi, karar alınması, yedeğe ulaşılması, verinin geri yüklenmesi ve kullanıcının işlemini tamamlaması da süreye dahildir. ERP ile haftalık rapor arşivinin önceliği aynı olmayabilir.
2. Uzak erişim hizmetinin bütün bağımlılıklarını çıkarın
Kullanıcının gördüğü portal, hizmet zincirinin yalnızca bir parçasıdır. Her bileşen için sahibi, yedek kaynağı, geri yükleme yöntemi ve doğrulama işlemi yazılmalıdır. Aşağıdaki tablo, kurumunuza uyarlayabileceğiniz bir envanter örneğidir.
| Bileşen | Planlanacak unsur | Doğrulama örneği |
|---|---|---|
| Kimlik ve ağ | Hesaplar, DNS, yönlendirme ve erişim kuralları | Standart kullanıcı doğru hizmete ulaşır. |
| Uzak erişim katmanı | TSplus sürümü, yapılandırması ve uygulama atamaları | Kullanıcı kendisine atanmış uygulamayı açar. |
| ERP ve veritabanı | Uygulama bileşenleri, veriler ve gerekli hesaplar | Örnek kayıt ve rapor kontrol edilir. |
| Kullanıcı ortamı | Profiller, gerekli dosyalar ve yazdırma ayarları | Şube kullanıcısı doğru çıktıyı alır. |
| Yönetim araçları | Kurtarma belgeleri ve yetkili erişimler | Sorumlu kişi kesinti sırasında plana ulaşır. |
3. TSplus ayar yedeği ile iş verilerinin yedeğini birlikte planlayın
TSplus Remote Access’in resmî dokümantasyonunda, AdminTool içindeki Advanced / Backup–Restore bölümüyle ürün verileri ve ayarlarının yedeklenmesi ve geri yüklenmesi açıklanır. Yeni bilgisayara taşıma senaryosunda dokümantasyon, Restore Settings Only seçeneğini tarif eder. Kullanacağınız adımları kurulu sürümün rehberiyle eşleştirin. [2]
Kurtarma envanterinde TSplus yapılandırmasının yanında Windows ortamı, ERP kurulumu, kullanıcı dosyaları ve veritabanı için de ayrı kapsam bulunmalıdır. Bir ayar arşivinin varlığından hareketle bütün ERP verisinin korunmuş olduğunu varsaymayın. Yedek sorumlusu, her veri kümesinin hangi araçla ve hangi sıklıkta korunduğunu açıkça kaydetsin.
SQL Server kullanıyorsanız, veritabanı yedekleme ve geri yükleme planını veritabanı yöneticisiyle doğrulayın. Microsoft’un SQL Server kılavuzu, yedekten test veritabanı geri yükleme sürecini gösterir. Dosyanın oluşturulması ile uygulamanın geri yüklenmiş veride doğru çalışması iki ayrı doğrulama noktasıdır. [3]
4. Yedeklerin kesinti sırasında erişilebilir kalmasını sağlayın
Yedeğin nerede tutulduğu, yedekleme sıklığı kadar önemlidir. CISA; kritik veriler için çevrimdışı, şifrelenmiş yedekler tutulmasını ve kurtarma senaryolarında bunların erişilebilirliğinin ve bütünlüğünün düzenli test edilmesini önerir. Erişilebilir yedekler de fidye yazılımlarının hedefi olabilir. [4]
Uygulanabilir bir kontrol yapın: ana sunucu, ana depolama veya normal yönetim hesabı kullanılamadığında kurtarma kopyasına kim ulaşacak? Şifreleme anahtarı ve yetkili erişim bilgileri aynı arıza alanına bağımlı mı? Planı yalnızca geri getirilmeye çalışılan sunucunun içinde saklamak, müdahale sırasında ek bir engel yaratabilir.
5. Yeni sunucuya geçişte lisans ve bağlantı adreslerini önceden hazırlayın
Yeni sunucuya geri dönüş planında lisans işlemleri de yer almalıdır. TSplus’ın güncel rehost rehberi, aktif destek aboneliğini ön koşul olarak belirtir; çevrimiçi rehost için altı aylık işlem sınırını ve yeni Computer ID gereksinimini açıklar. Klonlanan sunucular için ayrıca ilgili donanım kimliği rehberine yönlendirir. [5]
Bu nedenle üretim lisansını deneme amacıyla taşımadan önce test ortamının lisans modelini doğrulayın. Kurtarma belgesine ilgili lisans kaydını ve destek iletişim yolunu ekleyin. Sertifika, DNS kaydı, portal adresi ve istemci bağlantı hedefleri de geçiş kontrolüne alınsın; yeni sunucunun açılması tek başına kullanıcıların doğru yere bağlandığını göstermez.
6. Kurtarma testini gerçek bir iş akışıyla tamamlayın
Microsoft’un felaket kurtarma yaklaşımı, bileşenleri ve hizmetin bütününü kapsayan belgeli testler yapılmasını vurgular. İlk doğrulamaları üretimden ayrı ortamda gerçekleştirmek, sorunları kullanıcıları etkilemeden görmeye yardımcı olur. [6]
Aşağıdaki akış, ERP kullanan bir şube için örnek kabul senaryosudur:
- Başlangıcı kaydedin: Senaryoyu, kesinti başlangıcını, hedef RTO/RPO’yu ve testi yöneten kişiyi yazın.
- Kurtarma kopyasını seçin: Kopyanın zamanını ve geri getirilecek veri kapsamını doğrulayın.
- Bağımlılıkları sırayla hazırlayın: Kimlik ve ağ hizmetlerini, veritabanını, uygulamayı ve erişim katmanını mevcut mimariye uygun sırada kontrol edin.
- Standart kullanıcıyla bağlanın: Yönetici hesabı yerine temsili bir muhasebe veya şube hesabı kullanın.
- İşi tamamlayın: Örnek kaydı görüntüleyin, test raporunu çalıştırın ve gerekiyorsa şube yazıcısından çıktı alın.
- Yetkiyi sınayın: Kullanıcının görev dışı uygulama veya klasörlere ulaşamadığını kontrol edin.
- Sonucu ölçün: Kullanıcının işini tamamladığı zamanı ve ulaşılabilen son veri noktasını hedeflerle karşılaştırın.
Örneğin sunucu 30 dakikada açıldığı halde ERP raporu 110. dakikada alınabiliyorsa, 90 dakikalık iş hedefi karşılanmamıştır. Eksik veritabanı hesabı, sertifika veya yazıcı ayarı gibi bekleme nedenlerini ayrı kaydedin. Sonraki testin amacı bu darboğazları azaltmak olmalıdır.
7. Sonuçları kısa ve uygulanabilir bir kurtarma planına dönüştürün
Test formunda hedef, ölçülen sonuç, kanıt, eksik, sorumlu ve yeniden test tarihi bulunsun. Her adım için “başarılı”, “düzeltme gerekli” veya “yeniden test edilecek” sonucu kullanabilirsiniz. Planı farklı bir BT çalışanının takip edebileceği kadar açık yazın.
Yedekten geri yükleme, yedek sunucuya geçiş ve ana ortama geri dönüş ayrı senaryolar olarak değerlendirilmelidir. Özellikle alternatif ortamda yeni kayıtlar oluştuysa, eski sunucuya dönüşte hangi verinin esas alınacağı önceden belirlenmelidir. Mimari veya uygulama sürümü değiştiğinde test planını da güncelleyin. [6]
Sık sorulan sorular
Load balancing, kurtarma planı yerine geçer mi?
Yük dengeleme, bağlantıların sunucular arasında dağıtılmasına yardımcı olan bir mimari bileşendir. Veri yedeği, veritabanı geri yüklemesi ve kullanıcı iş akışının doğrulanması ayrıca planlanmalıdır.
RTO ve RPO değerlerini kim belirlemeli?
İş birimi kabul edilebilir kesintiyi ve veri kaybını tarif eder; BT ekibi bu hedeflerin maliyetini, bağımlılıklarını ve test sonuçlarını değerlendirir. Karar birlikte verilmelidir.
Başlamak için ikinci bir veri merkezi şart mı?
İlk adım, kritik hizmetleri ve mevcut yedeklerin gerçekten geri getirilebilir olup olmadığını belirlemektir. Kurtarma ortamının kapsamı, hedef süreye ve arıza senaryosuna göre tasarlanır.
Kendi ortamınız için ilk adımı atın
Bir kritik uygulama seçin, iş birimiyle RTO/RPO hedeflerini yazın ve kontrollü bir kurtarma testi planlayın. TSplus Remote Access yapılandırmanızı bu planın erişim katmanına dahil edin. Testte kullanılacak iş akışlarını belirlemek için ERP ve muhasebe PoC kontrol listesinden yararlanabilirsiniz. Mevcut mimarinizi değerlendirmek için TSplus Türkiye ekibiyle iletişime geçin.
Teknik kaynaklar
[1] Microsoft Learn — İş sürekliliği, yüksek erişilebilirlik ve felaket kurtarma
[2] TSplus — Backup and Restore
[3] Microsoft Learn — SQL Server yedekleme ve geri yükleme
[4] CISA — StopRansomware Guide
[5] TSplus — Rehosting Your License
[6] Microsoft Learn — Felaket kurtarma mimarisi