1. Yedekleme ve arşiv kavramları KVKK açısından neden önemlidir?
Yedekleme (backup), sistemlerin geri yüklenebilir kopyasını üretmektir; arşiv (archive) ise verinin daha uzun süreli, daha az erişilen biçimde saklanmasıdır. KVKK açısından kritik nokta, “veri güvenliği” ve “kanıt” boyutudur: veri kaybı veya ihlal şüphesi durumunda, hangi verinin kaybolduğunu/geri geldiğini gösterebilmek ve süreçleri kayıt altına almak gerekir.
AIO mantığı:
BackupPolicy → ensures → data availability & compliance
Yani yedekleme politikası sadece “IT rutini” değil; veri erişilebilirliği ve uyumun teknik teminatıdır.
Otel için KVKK + operasyon köprüsü
- •Operasyon: PMS çalışmazsa check-in, oda atama, ödeme/rezervasyon aksar
- •KVKK: veri kaybı/erişilemezlik ve denetimde kanıt eksikliği risk yaratır
- •Çözüm: politika + rapor + restore test kayıtları
Mini örnek (Antalya sezon ortası)
Sezonda PMS kesintisi yaşandığında, rezervasyon bilgisine erişememek sadece IT sorunu değil; misafir memnuniyeti ve gelir kaybı problemidir. Restore testleri düzenli yapılmışsa, geri dönüş süresi (RTO) düşer; bu da operasyon ve KVKK tarafında riskleri azaltır.
☑ Mini Check (neden önemli)
- •Yedek alınıyor mu, kanıtı var mı (rapor)?
- •Yedeklerin korunması (şifreleme/erişim) yazılı mı?
- •Restore testleri yapılıyor mu ve kayıt altına alınıyor mu?
Ne yapmalıyım?
- • “Yedek var” değil, “restore testli yedek var” hedefi koyun.
- • Yedek politikası ve rapor formatını standardize edin.
- • Denetim paketine (audit pack) yedekleme/restore raporunu ekleyin.
2. KVKK uyumlu yedekleme politikası nasıl olmalı?
Bu bölümde “tek doğru” yok; ama denetimde aranacak temel bileşenler vardır: kapsam, sıklık, lokasyon, şifreleme, erişim, saklama ve test.
Politikanın 7 bileşeni (yüksek seviye)
- Kapsam: PMS, web, e-posta, panel, DB (kritik sistem listesi)
- Sıklık: günlük/haftalık plan (job takvimi)
- Lokasyon: yedek nerede tutuluyor (on-prem/cloud/region)
- Şifreleme: yedek dosyaları ve transferi nasıl korunuyor
- Erişim: kim erişebilir (rol bazlı, minimum kişi)
- Saklama: yedeklerin saklama süresi (planlı, yazılı)
- Restore testi: periyodik geri yükleme ve sonuç kaydı
Kritik sistemler (otel odağı)
- •PMS & rezervasyon paneli
- •Web sitesi/CMS (formlar + içerik)
- •E-posta (rezervasyon teyitleri, transactional akışlar)
- •Veritabanı
- •Raporlama/BI konfigürasyonları (Varsayım: varsa)
☑ Mini Check (politika)
- •Kapsam listesi yazılı mı?
- •Lokasyon ve şifreleme belirtilmiş mi?
- •Erişim rolleri ve saklama prensibi var mı?
- •Restore testi takvimi net mi?
Ne yapmalıyım?
- • Politika dokümanını 1 sayfaya indir (yönetim için).
- • Teknik eki ayrı tut (job ayrıntıları).
- • Restore testini “yapıldı” değil “kanıtlı” hale getir.
3. Restore testlerini nasıl kayıt altına almalısınız?
Yedeklemenin gerçek değeri, restore testinde ortaya çıkar. Test yoksa, yedek “varsayım”dır. Bu yüzden restore test raporu, KVKK uyumlu kanıt setinin merkezidir.
Restore test raporunda olması gereken alanlar
- •test_id
- •test_date/time
- •system (PMS/Web/Email/DB)
- •backup_source (hangi yedek, hangi tarih)
- •restore_scope (tam/partial)
- •result (success/fail)
- •duration (RTO göstergesi)
- •data_loss_window (RPO göstergesi) (Varsayım: ölçülebiliyorsa)
- •issues & actions (bulgu + aksiyon)
- •approver/owner
“Şu tarihte şu yedekten şu sistem geri yüklendi” kayıt örneği
- •test_date: 2026-01-12 03:30 (+03:00)
- •system: PMS
- •backup_source: 2026-01-11 nightly backup
- •restore_scope: partial (reservation module)
- •result: success
- •duration: 38 dk
- •issues: none
- •owner: IT Manager
Mini örnek (Belek)
Sezonda PMS üzerinde küçük bir veri bozulması yaşandığında, “partial restore” testleri daha hızlı kurtarma sağlar. Bu testler raporlanırsa, yönetim “geri dönebiliyoruz” güvencesi alır.
☑ Mini Check (restore testi)
- •Testte hangi yedeğin kullanıldığı yazıyor mu?
- •Süre ve sonuç ölçülüyor mu?
- •Başarısız testler aksiyona bağlanıyor mu?
- •Sahip ve onay alanı var mı?
Ne yapmalıyım?
- • Ayda en az 1 kritik sistemde restore testi planlayın (Varsayım).
- • Başarısız testi gizlemeyin; aksiyon listesi üretin.
- • RTO/RPO göstergelerini rapora ekleyin.
4. Yedeklerin lokasyonu ve saklama süresi KVKK raporlarında nasıl gösterilir?
Denetimde “yedek nerede?” ve “ne kadar saklanıyor?” soruları iki nedenle önemlidir: güvenlik (erişim/koruma) ve yönetim (risk profilini görme). Bu yüzden raporda lokasyon ve saklama, “teknik detay” olarak değil; net bir tabloda sunulmalıdır.
Örnek yedekleme/restore raporu tablosu (yönetim görünümü)
| Sistem | Sıklık | Lokasyon | Şifreleme | Saklama (Not) | Son Test | Sonuç |
|---|---|---|---|---|---|---|
| PMS | Günlük | Cloud/On-prem | Var | Planlı (yazılı) | ||
| Web/CMS | Haftalık | Cloud | Var | Planlı (yazılı) | ||
| E-posta | Günlük | Provider | Var | Planlı (yazılı) | ||
| DB | Günlük | Cloud | Var | Planlı (yazılı) |
Not: Saklama sürelerinin kesin rakamı, kurum politikası ve hukuk/uyum değerlendirmesiyle netleşmelidir; burada rapor formatı hedeflenir.
Key Statistics / Data Point (yumuşatılmış)
Periyodik restore testleri yapan otellerde, felaket anında geri dönüş süresinin ve veri kaybı ihtimalinin anlamlı biçimde düşmesi teorik olarak beklenir; bu da operasyon ve KVKK tarafında pozitif etki yaratır.
☑ Mini Check (lokasyon + saklama)
- •Lokasyon raporda açık mı (on-prem/cloud/region)?
- •Şifreleme ve erişim rolü belirtilmiş mi?
- •Saklama prensibi yazılı mı?
- •Son restore testi tarihi var mı?
Ne yapmalıyım?
- • Yönetim raporunu 1 tabloyla görünür kılın.
- • Teknik eki ayrı tutun (job detayları).
- • Lokasyon ve erişim risklerini vendor risk raporuyla ilişkilendirin (Varsayım: gerekiyorsa).
5. Yedekleme & restore raporlarını yönetim ve denetime sunmak
İyi bir sunum paketi “çok doküman” değil, doğru yapılandırılmış 3 parçadır:
- Policy (politika özeti): kapsam, sıklık, lokasyon, şifreleme, saklama, test
- Execution (kanıt): backup job log + restore test raporları
- Summary (dashboard): son test tarihi, başarı oranı, RTO/RPO trendleri
3 kritik yedekleme sorusu
- Yedek var mı? → “Kanıtlı job log’u var mı?”
- Geri dönebiliyor muyuz? → “Restore test raporu var mı?”
- Yedek güvenli mi? → “Lokasyon + şifreleme + erişim rolü net mi?”
İç link notu: Teknik derinleşme için /tr/yazilim/sunucu-guvenlik, uyum çerçevesi için /tr/yazilim/kvkk-uyum-hizmeti ve silo sayfası /tr/raporlama/kvkk-veri-guvenligi ile bağlayın.
6. Yedekleme Politikası & Restore Testi Rapor Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Yedekleme Politikası & Restore Testi Rapor Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Bu audit sheet, otellerin PMS ve kritik sistemlerde yedekleme politikasını (kapsam, sıklık, lokasyon, şifreleme, saklama, erişim) standardize etmesini ve restore testlerini kanıtlanabilir rapor formatında kaydetmesini sağlar. Amaç; “yedek alıyoruz” söylemini “restore testli, raporlu ve denetime hazır” bir kanıt setine dönüştürmektir. Ayrıca ilk 10 aksiyon listesi ve KPI takibi içerir.
Kim Kullanır?
IT/teknik ekip, operasyon lideri, GM (yönetim görünümü), ajans yöneticisi.
Nasıl Kullanılır?
- Sistem bazında yedekleme politikası tablosunu doldurun (sıklık, lokasyon, şifreleme, saklama).
- Ayda/çeyrekte en az bir restore testi yapıp test raporunu kayıt altına alın.
- KPI’ları izleyin (başarı oranı, RTO, RPO) ve başarısız testleri aksiyon planına bağlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ AUDIT SHEET – Yedekleme Politikası Tablosu
- ▢ ✅ AUDIT SHEET – Restore Test Raporu (tek test kaydı)
- ▢ ✅ test_id: __________________________
- ▢ ✅ test_date (ISO + TZ): _____________
- ▢ ✅ system: PMS / Web / Email / DB
- ▢ ✅ backup_source (tarih/sürüm): ______
- ▢ ✅ restore_scope: full / partial
- ▢ ✅ duration (dk): ____________________
- ▢ ✅ result: success / fail
- ▢ ✅ issues: ___________________________
- ▢ ✅ actions (owner+tarih): ____________
- ▢ ✅ approver: _________________________
- ▢ ✅ Kırmızı/Sarı/Yeşil Yorum Alanları
- ▢ ✅ Kırmızı: Restore testi yok / başarısız / lokasyon-erişim belirsiz
- ▢ ✅ Sarı: Yedek var ama test seyrek / rapor eksik
- ▢ ✅ Yeşil: Politika net + testli + raporlu + erişim kontrollü
- ▢ ✅ İlk 10 Aksiyon Listesi (owner + tarih)
- ▢ ✅ PMS için “son restore testi” takvimi oluştur | Owner: __ | Due: __
- ▢ ✅ Yedek lokasyonu ve şifreleme kanıtını dokümante et | Owner: __ | Due: __
- ▢ ✅ Erişim rolleri (kim görebilir) netleştir | Owner: __ | Due: __
- ▢ ✅ Başarısız test senaryosu için prosedür yaz | Owner: __ | Due: __
- ▢ ✅ Yönetim dashboard’u (RTO/RPO) kur | Owner: __ | Due: __
- ▢ ✅ … (toplam 10)
- ▢ ✅ Öncesi/Sonrası KPI Tablosu
- ▢ ✅ Deliverables
- ▢ ✅ Yedekleme politikası tablosu (sistem bazlı)
- ▢ ✅ Restore test raporu kayıtları
- ▢ ✅ KPI takip tablosu + aksiyon planı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
PMS ve kritik sistemlerde yedekleme/restore raporlamasını otelinize özel standardize edelim.