PDKS yedekleme, ekranda “yedek başarıyla alındı” mesajını görmekle tamamlanmaz. Kabul edilebilir plan; seçilmiş bir tarihteki çalışan eşlemesini, ham giriş-çıkış olaylarını, vardiya kurallarını ve günlük-aylık puantajı ayrı bir test ortamına geri yükleyebilmeli, kaynakla aynı sonucu üretebilmeli ve kayıp süresini önceden belirlenen sınırın altında tutmalıdır. Bu zincirin bir halkası doğrulanamıyorsa yedek henüz bordro veya operasyon sürekliliği için kanıt sayılmaz.
Kararı altı kanıtla verin: kapsam envanteri, başarılı yedek kaydı, izole geri yükleme, ham olay mutabakatı, puantaj yeniden üretimi ve ölçülen kurtarma süresi. Önce RPO’yu, yani kabul edilebilecek en fazla veri kaybı aralığını; sonra RTO’yu, yani hizmetin yeniden kullanılabilir duruma gelmesi için kabul edilen azami süreyi yazın. Testte ölçülen kayıp RPO’yu veya geçen süre RTO’yu aşıyorsa tüm sisteme güvenmek yerine nedeni düzeltip aynı veri setiyle yeniden deneyin.
PDKS yedekleme için RPO ve RTO’yu iş diline çevirin
RPO ve RTO teknik ekibin tek başına belirleyeceği soyut değerler değildir. İnsan kaynakları ve puantaj ekibi, “son sağlam kopyadan sonra hangi giriş-çıkışlar yeniden toplanabilir?” ve “ay sonu kapanışı ne kadar bekleyebilir?” sorularını yanıtlamalıdır. Örneğin cihazlarda olay tutuluyorsa, yazılım veritabanı kaybından sonra bu olayların yeniden aktarılabildiği varsayılmamalı; seçilen terminal, gerçek aktarım yolu ve yazılım sürümüyle kontrollü olarak gösterilmelidir.
Tek bir hedef yerine iş dönemine göre eşik yazın. Normal günde kabul edilen kurtarma süresi, vardiya değişimi veya ay sonu puantaj kapanışında fazla uzun olabilir. Formda en az üç durum bulunsun: sıradan iş günü, yoğun vardiya geçişi ve aylık kapanış. Her durum için son güvenli kopya zamanı, yeniden toplanabilecek olay aralığı, sorumlu kişi ve durdurma eşiği ayrı kaydedilsin.
Yedeğe girmesi gereken dört veri katmanını ayırın
Bir PDKS yedeğini yalnız personel listesi veya yalnız veritabanı dosyası olarak tanımlamak eksik kalabilir. Kurumunuzun gerçek akışına göre dört katmanı envantere alın:
- Kimlik ve eşleme: Çalışan numarası, aktif-pasif durumu, departman ve terminaldeki kimliğin yazılımdaki kişiyle nasıl eşleştiği.
- Ham olay: Kaynak cihaz, kişi, zaman damgası ve olay türü. Hesaplanmış toplam, ham olayın yerine geçmez.
- Hesaplama bağlamı: Vardiya, çalışma planı, tolerans, izin ve fazla mesaiyi etkileyen kurallar ile bunların geçerlilik tarihleri.
- Çıktı ve iz: Günlük sonuç, aylık puantaj, yetkili düzeltme ve dönem kapanışına ilişkin kurumunuzda gerçekten kullanılan kayıtlar.
PDKS yedekleme kapsam formunda her katman için kaynak sistemi, yedeklenen nesneyi, sıklığı, saklama yerini, erişim sahibini ve geri yükleme sorumlusunu yazın. “Tüm veriler” gibi sınanamayan bir ifade kullanmayın. Bir nesne yedek dışında kalacaksa bunun puantajı yeniden üretmeye etkisini testten önce görünür hâle getirin.
Altı kanıtı aynı geri yükleme provasında toplayın
| Kontrol | Uygulanacak test | Geçme kanıtı | Durdurma nedeni |
|---|---|---|---|
| 1. Kapsam | Seçilen çalışan, gün ve vardiya için dört veri katmanını envanterle eşleştirin. | Her nesnenin kaynağı ve kopya zamanı bulunur. | Puantajı etkileyen bir nesnenin sahibi veya kopyası belirsizdir. |
| 2. Yedek kaydı | İşin başlangıç-bitiş zamanını, dosya ya da kopya kimliğini ve hata kaydını kontrol edin. | Test edilecek kopya tekil biçimde tanımlanır. | Yalnız “başarılı” mesajı vardır; hangi kopyanın üretildiği gösterilemez. |
| 3. İzole geri yükleme | Üretim verisini ezmeden, erişimi sınırlandırılmış ayrı bir ortama geri dönün. | Ortam açılır, sürüm ve tarih beklenen kopyayla eşleşir. | Deneme üretim sistemini veya güncel kayıtları değiştirme riski taşır. |
| 4. Ham olay | Önceden seçilmiş kişi ve zaman aralığındaki olay sayısını, kimliği ve zaman damgasını kaynakla karşılaştırın. | Eksik, fazla veya başka kişiye bağlı olay yoktur. | Açıklanamayan kayıt kaybı, tekrar veya kimlik farkı vardır. |
| 5. Puantaj | Aynı vardiya ve istisnalarla günlük sonucu ve aylık toplamı yeniden hesaplayın. | Kaynak sonuçla satır bazında uzlaşır; varsa izinli fark açıklanır. | Ham olay doğru olsa da çalışma süresi, devamsızlık veya fazla mesai değişir. |
| 6. Süre ve yetki | Talebin açılmasından kullanıcının doğrulanmış sonuca erişmesine kadar süreyi ve onay zincirini ölçün. | RPO/RTO sınırları geçilmez; işlem sahibi ve onaylayan bellidir. | Süre hedefi aşılır veya geri yükleme kontrolsüz bir hesapla yapılır. |
Bu tabloyu boş bir test verisiyle değil, küçük ama ayırt edici bir örnekle çalıştırın: normal giriş-çıkış, geceye taşan vardiya, izinli gün, eksik okutma ve yetkili düzeltme içeren birkaç çalışan seçin. Böylece dosyanın açılması ile iş sonucunun geri gelmesi arasındaki fark görünür olur.
TigerBio veri akışında doğrulanacak sınırı doğru kurun
TigerBio’nun Personel Devam Kontrol Yazılımı sayfası giriş-çıkış, geç gelme, erken çıkma, devamsızlık, izin ile günlük ve aylık puantaj başlıklarını açıkça adlandırır. Bu başlıklar geri yükleme provasında beklenen iş çıktısını kurmak için kullanılabilir. ham hareketten günlük ve aylık puantaja uzanan yazılım kapsamını test envanterinizle eşleştirin; kullanılan formül, geçmiş sürüm davranışı veya otomatik geri yükleme sonucu hakkında sayfada olmayan bir varsayım eklemeyin.
Cihazdan yazılıma ulaşan kayıt da ayrıca sınanmalıdır. TigerBio’nun USB, TCP/IP, Wi-Fi ve geçerli IP yollarını ayıran veri aktarımı rehberi, yöntemin modele göre değiştiğini belirtir. Provada gerçek projedeki yolu kullanın; geri yüklenen veritabanına son yedekten sonra oluşan olayların yeniden aktarılıp aktarılamadığını ve tekrar üretip üretmediğini kontrollü olaylarla ölçün.
İncelenen resmî TigerBio sayfaları yedekleme sıklığı, saklama süresi, geri yükleme adımı, RPO veya RTO taahhüdü belirtmiyor. Bu nedenle PDKS yedekleme sonucunu bir katalog özelliği gibi sunmayın. Teklif edilen mimari ve teslim edilen sürüm üzerinde kimin yedek aldığı, hangi katmanların kopyalandığı, kopyanın nerede tutulduğu ve geri dönüşün nasıl kanıtlandığı yazılı kabul maddesi olsun.
Üç arıza senaryosuyla planın zayıf halkasını bulun
Son yedekten sonraki cihaz olayları
Yedeği belirli bir saate geri döndürün ve o saatten sonra terminalde oluşturulmuş kontrollü iki olayı ele alın. Olayların tekrar aktarılması mümkünse eksik ve tekrar sayısını sıfır hedefiyle uzlaştırın. Mümkün değilse bu aralığı RPO kaybı olarak açıkça kaydedin; cihazın olay tuttuğu varsayımını tek başına kurtarma planı saymayın.
Vardiya kuralı ile ham olayın farklı tarihlerde olması
Bir vardiya kuralının değiştiği günün öncesinden ve sonrasından örnek seçin. Geri yükleme sonrasında ham olay aynı kalırken doğru tarihli kuralın uygulanıp uygulanmadığını kontrol edin. Bu test, yalnız olayların değil, hesaplama bağlamının da geri dönmesi gerektiğini gösterir. Ay sonu mutabakatını ayrıntılandırmak için kaynak kayıttan kapanış sonucuna uzanan puantaj testini ayrı kontrol listesi olarak kullanabilirsiniz.
Yanlış veya bozuk kopya seçimi
Listeye kasıtlı olarak eski bir kopya ekleyin ve operatörün tarih, ortam ve kopya kimliğiyle hatayı fark edip etmediğini sınayın. PDKS yedekleme prosedürü yalnız doğru dosyayı geri açmayı değil, yanlış kopyayı üretime taşımadan durdurmayı da sağlamalıdır. Kopya adlandırması, erişim yetkisi ve onay adımı bu senaryoda birlikte ölçülür.
Güvenlik ve saklama kararını kısa ama somut tutun
Yedek, üretim verisinin başka bir kopyasıdır; erişim, saklama ve silme kararları bu kopyayı da kapsamalıdır. NIST SP 800-34 süreklilik planlama rehberi kurtarma stratejisinin iş etkisi ve testlerle ilişkilendirilmesini ele alır. CISA #StopRansomware rehberi kritik hizmetlerin çevrimdışı ve şifreli yedeklerden öncelik sırasıyla geri yüklenmesine dikkat çeker. KVKK teknik ve idari tedbirler rehberi de kişisel veri güvenliği için risk temelli bir çerçeve sunar.
Bu kaynaklar tek başına kurumunuza özgü saklama süresi veya hukuki sonuç belirlemez. Hangi kopyanın ne kadar tutulacağına, kimlerin erişeceğine ve test verisinin nasıl silineceğine veri envanteri, iş gereksinimi ve yetkili danışmanlıkla karar verin. Teknik kabul formunda ise en azından erişim sahibi, saklama yeri, şifreleme durumu, silme sorumlusu ve son geri yükleme tarihi görünür olsun.
Kabul kararını üç net sonuçtan biriyle kapatın
Kabul et: Dört veri katmanı kapsamda, izole geri yükleme başarılı, ham olay ve puantaj kaynakla uyumlu, ölçülen kayıp ile süre RPO/RTO içinde ve yetki zinciri kayıtlıdır. Sınırlı pilotu sürdür: İş sonucu doğru olsa da süre, otomasyon veya sorumluluk boşluğu vardır; eksik maddeye tarih ve sahip atayıp aynı provayı tekrar edin. Durdur: Hangi kopyanın kullanıldığı bilinmiyor, ham olay kayboluyor veya tekrarlanıyor, kişi eşlemesi bozuluyor ya da puantaj açıklanamayan biçimde değişiyorsa canlı ortam için onay vermeyin.
Demo veya teklif görüşmesine boş bir “yedek var mı?” sorusuyla değil, bu altı kanıtı içeren test formuyla gidin. Web tabanlı çalışma ve personel devam kapsamını kendi RPO/RTO hedeflerinizle değerlendirmek için Kontrol Yazılımı’nı geri yükleme kabul formunuzla sınayın; kabulü ürün adından değil, gerçek ortamda geri gelen olay ve puantaj sonucundan verin.
