Rezervasyon & Misafir Verisi Yedekleme Sistemi

Bu hizmet, rezervasyon ve misafir verisinin işletmenin bel kemiği olduğu her konaklama tesisi için kritik öneme sahiptir. Tesisin büyüklüğü veya teknoloji olgunluğu değil, veri kaybının operasyonu ne kadar süre felç edeceği bu sistemin gerekliliğini belirler.

• PMS kullanan oteller: Opera, Protel, Hestia veya özel geliştirilen herhangi bir Property Management System üzerinde çalışan tesisler. Veritabanı yedeklemesi genellikle varsayılan kurulumda yeterince yapılandırılmamıştır; sağlayıcının kendi yedek politikası tek veri merkezini kapsarken coğrafi felaket senaryolarını dışarıda bırakabilmektedir.
• Excel veya bulut tablo kullanan küçük tesisler: Pansiyon ve butik otellerin büyük kısmı rezervasyonlarını hâlâ Excel ya da Google Sheets'te tutar. Bu dosyalar silindiğinde, yanlışlıkla üzerine yazıldığında veya hesap erişimi kesildiğinde kurtarma imkânı çoğu zaman sıfırdır. Küçük tesisin kurtarma maliyeti aslında büyük tesise oranla çok daha yüksektir çünkü yedek bütçesi ayrılmamıştır.
• Birden fazla kanal üzerinden rezervasyon alan işletmeler: Booking.com, Airbnb ve kendi sitesi üzerinden gelen rezervasyonları tek havuzda toplayan tesisler, veri tutarlılığını yedekleme katmanıyla güvence altına almalıdır. Kanallardan birinin verisi kaybolduğunda bütünlük sorunu tüm operasyonu etkiler.
• Muhasebe ve fatura kaydı tutan işletmeler: ÖKC entegrasyonu, e-fatura veya misafir bazlı harcama takibi yapan tesisler için finansal kayıtların korunması yasal ve operasyonel zorunluluktur. Gelir İdaresi kayıt saklama yükümlülükleri de bu kapsamı belirler.
• Siber saldırı kaygısı taşıyan yöneticiler: Fidye yazılımı saldırıları otelcilik sektörünü giderek daha sık hedef almaktadır. Konuk rezervasyon veritabanı, fidye yazılımı operatörleri için yüksek değerli bir kaldıraçtır çünkü sezon ortasında veri erişiminin kesilmesi ciddi baskı yaratır. Çevrimdışı ve coğrafi olarak ayrı tutulan yedek, bu saldırıyı kolayca atlatmanın tek güvenilir yoludur.
• IT personeli bulunmayan küçük ve orta ölçekli tesisler: Yedekleme durumunu izleyecek, arızada müdahale edecek teknik ekibi olmayan işletmeler için otomatik izleme ve uyarı sistemi, bir IT personelinin yerini tutacak güvenlik ağı oluşturur.

Sistemi kurmanın en kötü zamanı bir kriz anıdır. Yedekleme altyapısı ihtiyaç duyulmadan önce devreye alınmalıdır; aksi hâlde hazır olmak değil, yeniden inşa etmek söz konusu olur.

Rezervasyon ve misafir verisi kaybının gerçek maliyeti görünenden çok daha büyüktür. Ani kesintinin operasyonel bedeli ile itibar hasarının uzun vadeli bedeli toplandığında yedekleme altyapısına yapılan yatırım her zaman karlıdır.

Tek Nokta Başarısızlığı

PMS veritabanı tek sunucuda tutuluyor ve günlük yedek alınmıyorsa bir donanım arızası tüm misafir geçmişini, açık rezervasyonları ve fatura kayıtlarını yok eder. Daha da kritik olan; yedek mevcut olsa bile hiç test edilmemişse kurtarma girişimi sonuçsuz kalabilir. Gerçek kurtarma kapasitesi, kriz anında değil öncesinde doğrulanmak zorundadır.

Fidye Yazılımı Senaryosu

Fidye yazılımı, ağa bağlı tüm sürücüleri ve sürekli çevrimiçi yedekleri de şifreler. Bu durumda kurtarılabilir tek veri, ağdan yalıtılmış (air-gapped) veya değişmez depolama (immutable storage) ortamında tutulan yedektir. Böyle bir yedek yoksa fidye ödemeyi düşünmek kaçınılmaz hâle gelir; ödeme de verinin tam olarak geri geleceğini garanti etmez. Otelcilik sektöründe sezon ortasındaki bir fidye saldırısı özellikle yıkıcıdır.

İnsan Hatası ve Kazara Silme

Ön büro personelinin yanlışlıkla toplu rezervasyon silmesi, sistem güncellemesi sırasında veritabanının bozulması veya yanlış CSV içe aktarımı sık karşılaşılan senaryolardır. Geri alma geçmişi olmayan ve yedek bulunmayan sistemlerde bu hatalar geri dönüşü olmayan kayıplara dönüşür. Dakikalık yedekleme noktası (RPO) tanımlayan sistem bu hasarı minimize eder.

Sezon Arası Risk

Düşük sezonda IT bakımı ertelenir, güncel olmayan yazılımlar güvenlik açığı taşımaya başlar ve kritik donanım arızaları gün yüzüne çıkar. Sezon başında tüm operasyonun yeniden başlaması gerektiğinde bir veri kaybı en kötü zamanda en büyük hasarı yaratır. Otomatik yedekleme izleme sistemi sezon dışında da tetiklenip tetiklenmediğini kontrol eder ve yöneticiye düzenli sağlık raporu gönderir.

Uyumsuz Yedek Formatı

Bazı sistemler yedek alıyor gibi görünse de üretilen dosya asıl sistemin güncel sürümüyle uyumsuz olabilir. Yedek kurtarma testi yapılmadıkça bu uyumsuzluk kriz anına kadar fark edilmez. Gerçek kurtarma simülasyonu bu sorunu erkenden ortaya çıkarır.

1. Veri Haritalama ve Envanter: Hangi sistemlerin hangi veritabanlarını, dosyaları ve bulut hesaplarını kullandığı ayrıntılı biçimde envantere alınır. PMS, rezervasyon kanalı entegrasyon verileri, muhasebe yazılımı, yerel dosya paylaşımları ve e-posta hesapları bu aşamada kapsama dahil edilir. Her sistemin veri hacmi, değişim hızı ve kurtarma önceliği belirlenir.
2. RPO ve RTO Hedef Belirleme: İşletmenin tolere edebileceği maksimum veri kaybı süresi (Recovery Point Objective) ve sistem kesintisi süresi (Recovery Time Objective) belirlenir. Rezervasyon veritabanı için bir saatlik RPO uygunken arşiv verileri için günlük RPO yeterli olabilir. Bu hedefler teknik altyapıyı doğrudan şekillendirir ve maliyeti etkiler.
3. 3-2-1 Mimarisi Tasarımı: En az üç kopya, en az iki farklı depolama ortamı ve en az bir coğrafi olarak ayrı konum prensibine dayanan yedekleme mimarisi tasarlanır. Yerel yedek (NAS veya harici disk), birincil bulut (Türkiye bölgesi) ve ikincil bulut (farklı coğrafi bölge) katmanları belirlenir.
4. Otomasyon, Şifreleme ve Saklama Politikası: Belirlenen aralıklarla otomatik yedekleme süreçleri devreye alınır. Tüm yedekler kaynak noktasında AES-256 ile şifrelenerek iletilir ve depolanır; şifre anahtarları müşteriye teslim edilir. Günlük, haftalık ve aylık yedek döngüleri ile otomatik eski versiyon silme politikası yapılandırılır.
5. Gerçek Kurtarma Testi: Yedekleme kurulumu tamamlandıktan sonra gerçek kurtarma senaryosu simüle edilir. PMS veritabanı yedekten izole test ortamına geri yüklenerek kurtarma süresi ve veri bütünlüğü ölçülür. Test sonuçları raporlanır; başarısız veya eksik yönler kurulum aşamasında düzeltilir.
6. İzleme, Uyarı ve Raporlama: Yedekleme başarısız olduğunda, depolama alanı kritik eşiği aştığında veya beklenen zaman diliminde yedek tamamlanmadığında sorumluya SMS ve e-posta bildirimi gönderilir. Aylık yedekleme sağlık raporu otomatik olarak iletilir; yönetici herhangi bir teknik müdahale yapmaksızın sistemin durumunu takip edebilir.
7. Dokümantasyon ve bilgi transferi: Proje tamamlandığında teknik mimari belgesi, kullanıcı el kitabı ve yönetici başvuru kılavuzu teslim edilir. Bu belgeler ilerleyen dönemde ekip değişikliği veya sistem güncellemesi gerektiğinde bağımsız başvuru kaynağı işlevi görür. Kaynak kodun yorum yoğunluğu geliştiriciler için de sürdürülebilirlik sağlar.
8. Süregelen destek ve iyileştirme: Canlıya alım sonrasında ilk otuz gün boyunca öncelikli destek hattı aktif tutulur. Bu sürede misafir davranışlarından veya personel geri bildirimlerinden ortaya çıkan kullanılabilirlik iyileştirmeleri öncelikli olarak ele alınır. Altıncı ayda isteğe bağlı kapsamlı gözden geçirme oturumu düzenlenerek sistemin işletme hedefleriyle örtüşmeye devam ettiği doğrulanır.

Yedekleme sistemi, içerdiği kişisel veri nedeniyle en yüksek güvenlik standartlarına tabidir. Bir yedekleme altyapısının güvensiz olması; verinin bir kez değil, yedek alındığı her seferinde ek bir kopya üzerinden risk altına girmesi anlamına gelir.

• Uçtan uca şifreleme: Veriler kaynak sistemde şifrelenir, şifreli olarak iletilir ve depolama ortamında şifreli tutulur. Şifre çözme anahtarları yalnızca müşterinin yetkili yöneticisine aittir; hizmet sağlayıcı dahil hiçbir üçüncü taraf şifre çözme anahtarına sahip değildir.
• Erişim denetimi ve çok faktörlü kimlik doğrulama: Yedekleme yönetim paneline erişim çok faktörlü kimlik doğrulama ile korunur. Her erişim girişimi; kaynak IP, zaman ve işlem detayıyla loglanır. Yetkisiz erişim girişimi alarmı anında tetiklenir.
• KVKK uyumlu saklama ve imha: Misafir kişisel verisi içeren yedekler KVKK kapsamındaki saklama süresiyle uyumlu olarak yönetilir. Yasal saklama süresini aşan yedek kopyaları otomatik imha planlamasına alınır; imha işlemi zaman damgalı olarak kayıt altına alınır ve ibraz edilebilir rapor üretilir.
• Fidye yazılımına karşı yalıtım: En az bir yedek kopyası ağa sürekli bağlı olmayan değişmez depolama (immutable storage) yapısında tutulur. Fidye yazılımı bu kopyayı şifreleyemez veya silemez; bu kopya tam kurtarmanın güvencesidir.
• Erişim günlüğü ve anomali tespiti: Veritabanına veya yedek dosyalarına beklenmedik zamanda veya beklenmedik kaynaktan yapılan erişim girişimleri otomatik olarak işaretlenir ve yöneticiye bildirilir.
• Sunucu ve altyapı güvenliği: Sistemin çalıştığı altyapı güncel güvenlik yamaları alacak biçimde yönetilir. Bağımlılıklar bilinen zafiyet veritabanlarına karşı periyodik olarak taranır; kritik açık tespit edildiğinde yama önceliklendirilir ve teslim edilmiş sistemin etkilenip etkilenmediği müşteriye bildirilir.
• Yedekleme ve felaket kurtarma: Sistem veritabanı ve yapılandırma dosyaları günlük yedeklenir; yedekler şifreli olarak farklı bir coğrafi konumda saklanır. Veri kaybı durumunda kurtarma prosedürü önceden test edilmiş ve belgeli biçimde hazır tutulur.