PMS açılamadığında sorun yalnız bir yazılım ekranının kapanması değildir. Resepsiyon varış listesini göremez, oda durumları güncellenemez, folyo hareketleri işlenemez, ödeme ve kanal mesajları gecikebilir. Yedek dosyasının var olması da tek başına kurtarma garantisi vermez; dosya eksik, şifreli, bozuk, saldırganın eriştiği hesapta veya uygulamayla uyumsuz olabilir. Sağlam felaket kurtarma planı hangi işin ne kadar süre durabileceğini belirler, bağımsız yedekler üretir, geri yüklemeyi düzenli test eder ve sistem kapalıyken otelin nasıl çalışacağını önceden tanımlar.

What you will learn in this article
  • Yedekleme sıklığı takvimle değil, kabul edilebilir veri kaybı ve hizmet kesintisi hedefleriyle belirlenmelidir.
  • Veri tabanı kadar dosyalar, yapılandırmalar, entegrasyon kimlikleri, iş günü durumu ve güvenli anahtar yönetimi de kurtarma kapsamına alınmalıdır.
  • Gerçek güvence yedeğin alınması değil, izole ortamda geri yüklenip rezervasyon, folyo, oda durumu ve raporların doğrulanmasıdır.

Define critical hotel services and recovery targets first

Felaket kurtarma planı sunucu listesinden değil, otelin çalışması için gereken hizmetlerden başlamalıdır. Bugünün varış ve çıkışları, oda planı, rezervasyon arama, folyo, ödeme durumu, anahtar işlemleri, kimlik bildirimi, kanal bağlantıları, restoran ve muhasebe aktarımı aynı öncelikte olmayabilir. Her hizmet için sahibi, bağımlı olduğu sistem, kabul edilebilir kesinti ve manuel çalışma yöntemi yazılmalıdır. Böylece teknik ekip önce hangi bileşeni ayağa kaldıracağını, resepsiyon ise beklerken hangi kayıtları tutacağını bilir.

İki hedef ayrı tanımlanmalıdır. Kurtarma süresi hedefi, hizmetin ne kadar sürede yeniden çalışması gerektiğini; kurtarma noktası hedefi ise en fazla ne kadar güncel verinin kaybedilebileceğini anlatır. Örneğin yoğun giriş saatinde rezervasyon ve folyo için kısa hedef gerekirken arşiv raporu daha sonra açılabilir. Bu hedefler yalnız bilgi işlem tarafından seçilmemeli; ön büro, muhasebe, satış ve yönetim gerçek operasyon etkisini birlikte değerlendirmelidir.

  • Kritik hizmetler iş etkisine göre sıralandı ve her birine sorumlu atandı.
  • Kurtarma süresi ile kabul edilebilir veri kaybı ayrı hedefler olarak yazıldı.
  • Bağımlılıklar; kimlik, ağ, veri tabanı, depolama ve dış servis düzeyinde gösterildi.
  • Sistem kapalıyken kullanılacak manuel kayıt ve iletişim yöntemi önceden belirlendi.

Separate backups from production systems and administrator accounts

Üretim sunucusundaki ikinci klasör, gerçek anlamda bağımsız yedek değildir. Donanım arızası, yanlış silme, fidye yazılımı veya ele geçirilmiş yönetici hesabı aynı anda ana veriyi ve bağlı yedekleri etkileyebilir. CISA'nın fidye yazılımı rehberi çevrim dışı yedeklerin korunmasını, yedeklerin düzenli test edilmesini ve bulut kaynaklarının da güvenceye alınmasını önerir. En az bir kopya üretimden ayrı güvenlik sınırında, farklı kimlik bilgileriyle ve mümkünse sonradan değiştirilemez saklama özelliğiyle tutulmalıdır.

Yedekleme hesabı PMS yöneticisiyle aynı olmamalı, yalnız gerekli kaynağı okuyup hedefe yazabilmelidir. Üretim hesabının eski yedekleri silebilmesi engellenmeli; silme ve saklama politikası ayrı yetki ve ikinci onay kullanmalıdır. Başarı bildirimi kadar başarısız, geciken veya beklenenden küçük yedek de uyarı üretmelidir. Yedek sistemi internete açık ortak dosya alanına dönüşmemeli; erişim çok faktörlü kimlik doğrulama ve kaynak kısıtlarıyla korunmalıdır.

  • Yedek kopyaları üretim depolaması, hesapları ve ağ sınırından ayrıldı.
  • En az bir kopya çevrim dışı veya değiştirilemez saklama yöntemiyle korundu.
  • Yedek silme, saklama politikası değiştirme ve geri yükleme yetkileri ayrıştırıldı.
  • Başarısız, geciken ve olağan dışı boyuttaki yedekler merkezi uyarıya bağlandı.

List what must be recovered beyond the database

PMS veri tabanı geri geldiğinde uygulamanın eksiksiz çalışacağı varsayılmamalıdır. Misafir belge ekleri, fatura dosyaları, rapor şablonları, oda ve fiyat yapılandırmaları, kullanıcı rolleri, entegrasyon eşlemeleri, iş günü durumu, zamanlanmış görevler ve uygulama sürümü de gerekebilir. Şifreleme anahtarları veya sertifikalar kaybolursa yedek sağlam olsa bile veri açılamayabilir. Buna karşılık gizli anahtarları veriyle aynı dosyada saklamak da ayrı bir risk yaratır.

Bulut PMS kullanıldığında sağlayıcının altyapı yedeği ile otelin iş sürekliliği ihtiyacı birbirine karıştırılmamalıdır. Sözleşme; hangi verinin yedeklendiğini, saklama süresini, bölgeleri, geri yükleme talebini, hedef süreleri ve müşteriye verilecek dışa aktarmaları açıklamalıdır. Otel ayrıca günlük kritik listeleri güvenli ve sınırlı erişimli biçimde dışa aktarabilir. Ancak bu dosyalar yeni bir gölge veri tabanı haline gelmemeli, saklama ve imha planına dahil edilmelidir.

  • Veri tabanı, ekler, e-belgeler, şablonlar, yapılandırma ve sürüm bilgisi birlikte envantere alındı.
  • Anahtar ve sertifikalar ayrı güvenlik alanında, kurtarma prosedürüyle saklandı.
  • Bulut sağlayıcının yedek kapsamı, saklama süresi ve geri yükleme taahhüdü doğrulandı.
  • Operasyon dışa aktarmaları erişim, güncellik ve imha kurallarıyla sınırlandı.

Create consistent backups and verify integrity automatically

Çalışan bir PMS'in dosyalarını rastgele kopyalamak işlem bütünlüğünü bozabilir. Rezervasyon kaydı yazılırken folyo hareketi veya oda durumu farklı anda kopyalanırsa geri yüklenen sistem kendi içinde çelişebilir. Uygulamanın desteklediği veri tabanı anlık görüntüsü, işlem günlüğü veya tutarlı dışa aktarma yöntemi kullanılmalıdır. Yedek başlangıç ve bitiş zamanı, kaynak sürümü, kayıt sayısı, dosya boyutu ve hata durumu değiştirilemeyen bir işlem günlüğünde tutulmalıdır.

Her yedek için özet değer veya benzeri bütünlük kontrolü üretilmeli, aktarım ve saklama sırasında değişmediği doğrulanmalıdır. Yedek hem aktarımda hem depoda şifrelenmeli; ancak anahtar kaybı nedeniyle geri yüklenemez hale gelmemelidir. Saat senkronizasyonu önemlidir; farklı sistemlerdeki yanlış zaman, hangi yedeğin son sağlıklı durum olduğunu belirsizleştirir. Kontrol yalnız dosyanın açılmasına değil, uygulamanın beklediği şema ve sürümle uyumuna da bakmalıdır.

  • Yedekleme uygulama ve veri tabanının desteklediği tutarlı yöntemle çalıştırıldı.
  • Kaynak sürümü, zaman, boyut, kayıt sayısı ve sonuç denetim kaydına yazıldı.
  • Bütünlük değeri üretildi ve kopyalama sonrasında otomatik karşılaştırıldı.
  • Şifreleme anahtarlarının ayrı yedeği ve yetkili kurtarma prosedürü test edildi.

Test restores in isolation using realistic scenarios

Yedekleme ekranındaki yeşil işaret, geri dönüşün çalıştığını kanıtlamaz. Düzenli testte seçilen bir yedek izole ortama alınmalı, doğru uygulama sürümüyle geri yüklenmeli ve teknik hata vermeden açılması sağlanmalıdır. Ardından operasyon kontrol listesi çalıştırılmalıdır: örnek rezervasyon bulunuyor mu, misafir ve oda bağlantıları doğru mu, açık folyo bakiyesi tutuyor mu, iş günü tarihi doğru mu, e-belgeler açılıyor mu ve kritik rapor toplamları kaynak kayıtla eşleşiyor mu?

Test yalnız en yeni yedeği kullanmamalı; günlük, haftalık ve daha eski saklama katmanlarından örnek seçmelidir. Süre ölçülmeli ve tanımlanan kurtarma hedefiyle karşılaştırılmalıdır. Test verisi üretim ağından ayrılmalı, gerçek kişisel verilere erişim sınırlandırılmalı ve test sonunda güvenli biçimde kaldırılmalıdır. Başarısızlık normal bir bulgudur; sorun, düzeltme sahibi ve tekrar test tarihi kayda alınmadığında gerçek olayda yeniden yaşanır.

  • Farklı yaş ve saklama katmanlarından yedekler dönüşümlü olarak test edildi.
  • Rezervasyon, folyo, oda durumu, iş günü, belge ve rapor toplamları doğrulandı.
  • Gerçek geri yükleme süresi hedefle karşılaştırılıp darboğazlar kaydedildi.
  • Test ortamındaki kişisel veriler sınırlandı ve çalışma bitince güvenli şekilde kaldırıldı.

Plan how the hotel will operate while systems are unavailable

Felaket kurtarma teknik bir işlem sürerken otel hizmet vermeye devam eder. Resepsiyon için güncel varış, çıkış, oda ve bakiye listesi; kat hizmetleri için oda durumu; yönetim için irtibat zinciri erişilebilir olmalıdır. Manuel kayıt formu benzersiz işlem numarası, saat, kullanıcı, misafir, oda, tutar ve açıklama içermelidir. Kart bilgisi veya gereksiz kimlik verisi kâğıda ve ortak dosyaya yazılmamalıdır. Geçici yöntem, normal güvenlik kurallarını kaldıran sınırsız bir istisna olmamalıdır.

Sistem geri geldiğinde manuel işlemlerin hangi sırayla girileceği ve mükerrer kayıtların nasıl önleneceği belirlenmelidir. Önce iş günü ve oda durumu sabitlenmeli; ardından rezervasyon, ödeme ve folyo hareketleri kaynak belgesiyle işlenmelidir. Her geçici kayıt sisteme aktarıldığında eşleştirme işareti konmalı, iki kişiyle finansal kontrol yapılmalı ve fark raporu alınmalıdır. Kanal, ödeme ve e-belge entegrasyonları toplu olarak açılmadan önce kuyruk ve zaman aralığı kontrol edilmelidir.

  • Ön büro, kat hizmetleri, ödeme ve yönetim için çevrim dışı çalışma formları hazırlandı.
  • Geçici kayıtlarda gereksiz kişisel ve kart verisi toplanması engellendi.
  • Geri dönüşte işlem sırası, eşleştirme işareti ve çift kontrol tanımlandı.
  • Entegrasyonlar açılmadan önce bekleyen mesaj ve mükerrer işlem riski incelendi.

Use clean, controlled recovery after ransomware

Fidye yazılımı şüphesinde en hızlı yedeği üretime döndürmek güvenli olmayabilir. Saldırganın erişim yolu, zararlı yazılımın başlangıç zamanı ve etkilenen kimlik bilgileri belirlenmeden alınmış bir yedek de risk taşıyabilir. NIST'in olay müdahale yaklaşımı hazırlık, tespit, müdahale ve kurtarmayı kuruluşun risk yönetimiyle birleştirir. Kurtarma öncesinde olay ekibi, hangi tarihin temiz kabul edildiğini, hangi sistemlerin yeniden kurulacağını ve hangi hesapların sıfırlanacağını onaylamalıdır.

Yeni veya doğrulanmış temiz altyapı kurulmalı; yönetici parolaları, servis hesapları, API anahtarları ve oturumlar yenilenmelidir. Yedek doğrudan saldırı altındaki üretim ağına açılmamalı, taranıp izole ortamda doğrulanmalıdır. Önce sınırlı kullanıcı grubu ile hizmet açılır, log ve ağ hareketi yakından izlenir. Olay sırasında deliller korunmalı; acele temizlik, saldırının nedenini ve bildirim değerlendirmesi için gereken kayıtları ortadan kaldırmamalıdır.

  • Temiz kurtarma noktası olay ekibi ve sistem sahipleriyle birlikte seçildi.
  • Altyapı doğrulandı; yönetici, servis ve entegrasyon kimlik bilgileri yenilendi.
  • Yedek izole ortamda tarandı ve aşamalı kullanıcı grubuyla hizmete alındı.
  • Deliller, loglar ve karar kayıtları kurtarma temizliğinden önce korundu.

Apply data-protection, retention and governance rules to backups

Yedek, kişisel verinin farklı bir kopyasıdır; üretimden ayrıldığı için KVKK kapsamı dışında kalmaz. Genel ilkeler verinin belirli, açık ve meşru amaçlarla, amaçla bağlantılı ve ölçülü işlenmesini, doğru tutulmasını ve gerekli süre kadar saklanmasını gerektirir. Yedekteki misafir, çalışan, kimlik, folyo ve iletişim verileri için erişim, saklama ve imha kuralları tanımlanmalıdır. Her yedeği sonsuza kadar tutmak güvenlik ve ölçülülük sorununu büyütür.

KVKK'nın veri güvenliği rehberi risklerin belirlenmesi, çalışan eğitimi, yetki matrisi, erişim kayıtları, siber güvenlik, yedekleme ve test gibi idari ve teknik tedbirleri birlikte ele alır. Yedek erişimleri loglanmalı, geri yükleme talepleri onaylanmalı ve hizmet sağlayıcı sorumlulukları sözleşmede açıklanmalıdır. Saklama süresi dolan kopyalar doğrulanabilir biçimde silinmeli; yasal veya operasyonel nedenle korunan eski yedek geri döndüğünde güncelliğini yitirmiş kişisel verinin normal sisteme kontrolsüz biçimde yeniden eklenmesi engellenmelidir.

  • Yedekler kişisel veri envanteri, saklama ve imha politikasına dahil edildi.
  • Yedek görüntüleme, dışa aktarma ve geri yükleme erişimleri loglandı ve onaylandı.
  • Hizmet sağlayıcıların güvenlik, olay bildirimi ve silme sorumlulukları sözleşmeye yazıldı.
  • Eski yedekten dönen verinin güncellik ve silme taleplerini bozması engellendi.
Short answers

FAQ

Do we need separate backups when using a cloud PMS?

Sağlayıcının altyapı yedeği önemli olsa da kapsamı, saklama süresi, geri yükleme yöntemi ve hedef süreleri sözleşmeden doğrulanmalıdır. Otel ayrıca kritik operasyon listeleri ve veri dışa aktarma ihtiyacını, KVKK ve erişim kurallarıyla birlikte planlamalıdır.

How often should a hotel PMS be backed up?

Tek bir doğru süre yoktur. Sıklık, her hizmet için kabul edilebilir veri kaybı hedefinden türetilir. Rezervasyon ve folyo gibi sık değişen veriler daha kısa aralık ister; hedefler iş etkisi analiziyle belirlenip geri yükleme testleriyle doğrulanmalıdır.

Does opening a backup file mean the restore test passed?

Hayır. Dosya bütünlüğüne ek olarak uygun uygulama sürümünde geri yükleme yapılmalı; rezervasyon, folyo, oda durumu, iş günü, belgeler ve rapor toplamları operasyon ekibiyle kontrol edilmelidir.

Sources and updates

Operasyon önerileri tesisin kendi koşullarına uyarlanmalıdır. PMS ve kanal işleyişiyle ilgili bilgiler 29 Eylül 2026 tarihinde aşağıdaki resmi belgelerden kontrol edilmiştir.