Dava Takip Verisinin Yedeklenme Sıklığı

Dava takip verisi için herkese uyan tek bir yedekleme sıklığı yoktur; doğru sıklık, kaybetmeyi göze alabileceğiniz en uzun süreye göre belirlenir. Süre, tebligat, duruşma ve görev kayıtları gün içinde değiştiği için bu verileri en az her iş günü sonunda, mümkünse değişiklik oldukça yedeklemek gerekir. Müvekkil dosyası arşivi gibi daha yavaş değişen veriler daha seyrek yedeklenebilir. Sıklıktan da önemli olan, yedeğin gerçekten geri yüklenebildiğinin düzenli olarak denenmesidir.

Kısa Cevap: Yedekleme Sıklığını Ne Belirler?

Bir büroda yedekleme sıklığı sorusu aslında şu soruya indirgenir: bugün öğleden sonra verimiz silinse, geri döndüğümüzde en fazla ne kadarlık işi yeniden girmeyi kabul edebiliriz? Bu sürenin adı teknik literatürde kabul edilebilir veri kaybı penceresidir. Pencere bir gün ise yedeği günde en az bir kez, pencere birkaç saat ise daha sık almanız gerekir. Yani sıklığı yedekleme aracı değil, büronun risk iştahı belirler.

Avukatlık mesleğinde bu pencerenin dar tutulmasının nedeni basittir: dava takip verisi, süre kaçırma riskiyle doğrudan bağlantılıdır. Bir tebligatın işlendiği, bir duruşma tarihinin girildiği ya da bir sürenin son gününün hesaplandığı kayıt kaybolursa, hukuki süre bu kayba bakmadan işlemeye devam eder. Veri kaybı sürenizi durdurmaz, uzatmaz; yalnızca o süreyi hatırlatacak mekanizmayı elinizden alır.

Örneğin Ankara'da icra ağırlıklı çalışan bir avukat düşünelim. Sabah mesaisinde on dosyada yeni işlem girişi yapıyor, öğleden sonra duruşma notlarını ekliyor ve akşam üzeri tebligatları süre takvimine işliyor. Bürosunda yalnızca haftada bir yedek alınıyorsa, çarşamba günü bir disk arızası yaşandığında önceki cuma gününden bu yana girilen her kayıt gider. Yedek günlükse kayıp en fazla bir iş günüdür. Bu fark, kaçırılan bir sürenin tazminat riskiyle kıyaslandığında küçümsenemez.

Bu yüzden başlangıç kuralını şöyle koyabilirsiniz: süre, tebligat ve duruşma gibi tarihe bağlı kayıtlar için sıklığı en yüksek seviyede tutun; değişimi yavaş olan arşiv niteliğindeki belgeler için daha seyrek bir düzen kurun. Sonraki bölümlerde önce hangi verinin kapsama girdiğini, sonra bu verilerin ne kadar hızlı değiştiğini ve buna göre bir plan nasıl kurulacağını ele alıyoruz.

Bu çerçevenin bir yan faydası da büro içi konuşmayı somutlaştırmasıdır. "Yedeğimiz var" demek yerine "kayıp penceremiz bir iş günü, bunu yazılı olarak kabul ettik" diyebilen bir büro, hem ortaklar hem çalışanlar için net bir beklenti oluşturur. Beklenti netleşince, hangi verinin hangi sıklıkla korunacağı tartışması da kişisel görüşlere değil ölçülebilir bir ölçüte dayanır.

Dava Takip Verisi Tam Olarak Neleri Kapsar?

Yedekleme planına başlamadan önce neyi yedeklediğinizi netleştirmek gerekir. Pek çok büro yalnızca dosya sunucusundaki belgeleri düşünür; oysa dava takip verisi bundan çok daha geniştir. İş yönetiminde günlük kullanılan ve her biri farklı hızda değişen birkaç veri ailesi vardır. Bunları ayırmadan tek bir sıklık belirlemek, ya gereksiz maliyete ya da ciddi bir açığa yol açar.

Hızlı değişen kayıtlar

Süre kayıtları, tebligat girişleri, duruşma tarihleri, görev atamaları ve hatırlatma ayarları gün içinde defalarca değişir. Bir sekreter sabah bir tebligatı işler, öğlen bir duruşma ertelenir, akşam bir görev başka bir avukata devredilir. Bu verilerin her biri küçük olsa da kaybı en pahalı olanlardır; çünkü bir tarihin yanlış ya da eksik kalması doğrudan süre riskidir.

Orta hızda değişen kayıtlar

Dava künyesi, taraf bilgileri, müvekkil iletişim kayıtları, vekâlet bilgileri ve dosya notları genellikle dosya açılışında yoğun, sonrasında seyrek güncellenir. Bu kayıtlar kaybolursa yeniden oluşturulabilir ama zaman alır; yine de günlük yedek çoğu büro için yeterli bir dengedir.

Yavaş değişen belgeler

Dilekçe taslakları, sözleşme örnekleri, bilirkişi raporu kopyaları ve kapanmış dosya arşivi bir kez oluşturulur, nadiren değişir. Bunların yedeği daha seyrek alınabilir; ancak yedeğin varlığı, belgelerin KVKK kapsamında korunması yükümlülüğünü de ortadan kaldırmaz. Müvekkil verisi taşıyan her yedek, canlı veri kadar özenle saklanmalıdır.

Bir noktayı ayrıca belirtmek gerekir: UETS'e düşen e-tebligatın asıl kaydı PTT'nin işlettiği sistemdedir ve avukatlar için elektronik tebligat adresi almak zorunludur. Ancak büronuzun bu tebligattan türettiği süre hesabı, notlar, atama ve hatırlatma bilgileri sizin kendi takip verinizdir. Sistemdeki orijinal kayıt size aynı yapıyı geri vermez; bu türetilmiş veriyi yedekleme planınıza açıkça dahil etmeniz gerekir. Büyük bürolarda bu veri ailesini ayrı bir başlık altında listelemek, hangi kaydın hangi sistemde durduğunu unutmayı da engeller.

Veri Kaybının Büroya Gerçek Maliyeti

Veri kaybının maliyetini yalnızca yeniden giriş emeği olarak görmek eksik bir hesaptır. Asıl risk, kaybolan kaydın bir hukuki süreyle ilişkili olmasıdır. Elektronik tebligat, muhatabın elektronik adresine ulaştığı tarihi izleyen beşinci günün sonunda tebliğ edilmiş sayılır (Tebligat K. m.7/a). Muhatap tebligatı okumasa ya da açmasa bile bu kural işler. Dolayısıyla büronuzun takip kaydı silindiğinde, tebligat sistemde durmaya devam eder ve süre kendi akışında ilerler.

Benzer şekilde hukukta süreler adli tatilde durmaz. Son günü adli tatile rastlayan süre, tatilin bittiği günden itibaren bir hafta uzar (HMK m.104); ama bu uzama yalnızca son gün tatile denk geldiğinde işler ve her sürede geçerli değildir. Yedeksiz bir kayıp yaşayan büro, tatil dönemindeki bekleyen sürelerin hangisinin uzadığını, hangisinin uzamadığını yeniden çıkarmak zorunda kalır; bu da en çok hata yapılan alandır. Yani yedeğin yokluğu yalnızca veri değil, usul bilgisini de yeniden toplama yükü getirir.

Kayıp yalnızca süreyle sınırlı değildir. Müvekkile verilen sözler, duruşma hazırlık notları, bilirkişi raporuna itiraz için tuttuğunuz taslaklar ve görev dağılımı da gider. Büronun itibarı çoğu zaman tek bir kaçırılan süreyle sınanır. Müvekkil, avukatının kaydını kaybettiğini öğrendiğinde bunu teknik bir aksaklık olarak değil, özen eksikliği olarak okur.

Pratikte bu, yedeklemeyi bir IT işi olmaktan çıkarıp büro yönetimi kararına dönüştürür. Ortak avukat ya da büro yöneticisi, hangi verinin ne kadar kayba katlanabileceğini bilinçli olarak belirlemeli; teknik uygulama bu karara göre yapılmalıdır. Aksi hâlde sıklık, sistemin varsayılan ayarı kaç ise o olarak kalır ve bunu kimse bilinçli seçmemiş olur.

Kabul Edilebilir Kayıp Süresine Göre Sıklık Belirleme

Sıklığı belirlemenin en sağlam yolu, her veri ailesi için iki soruyu yanıtlamaktır. Birincisi: bu veri kaybolursa en fazla ne kadarlık girişi yeniden yapabiliriz? İkincisi: sistem çökerse ne kadar sürede yeniden çalışır hâle gelmeliyiz? Birinci soru yedek sıklığını, ikinci soru geri yükleme hızını belirler. İkisi birbirine karıştırılırsa sık yedek alan ama günlerce geri yükleyemeyen bir düzen ortaya çıkar.

Aşağıdaki tablo, veri ailesine göre kabul edilebilir kayıp ve buna uygun yaklaşımı özetler. Bunlar genel bir çerçevedir; büronuzun büyüklüğüne, dosya yoğunluğuna ve kullandığınız sisteme göre ayarlanmalıdır.

Tabloda dikkat edilmesi gereken nokta, sıklığın veri büyüklüğüne değil değişim hızına bağlı olmasıdır. Küçük ama kritik bir süre tablosu, büyük ama sabit bir arşivden çok daha sık yedeklenmelidir. Kapasite kaygısı yüzünden her şeyi haftada bire düşüren bürolar, tam da en değerli veriyi en savunmasız bırakır.

Örnek olarak, varsayımsal bir büroda sabah ve öğleden sonra olmak üzere iki ayrı iş yoğunluğu döneminin bulunduğunu düşünün. Bu büro için gün sonunda alınan tek yedek, öğleden sonra girilen kayıtları kapsar ama sabah yaşanan bir arıza durumunda önceki günün sonuna dönmeye zorlar. Bu varsayımsal büronun kayıp penceresi bir iş günüyse, bu seviye kabul edilebilir mi diye sorması ve cevabı yazılı hâle getirmesi gerekir. Cevap hayırsa sıklığı artırmak tek çözümdür.

Adım Adım Yedekleme Planı Kurmak

Plan kurmak, bir kez yapılıp unutulacak bir iş değildir; ancak ilk kurulumun doğru sırayla yapılması sonraki bakım yükünü ciddi biçimde azaltır. Aşağıdaki adımlar, küçük ve orta ölçekli bir hukuk bürosunun hayata geçirebileceği sade bir çerçeve sunar. Her adım bir öncekinin çıktısını kullanır.

1. Veri envanterini çıkarın. Süre, tebligat, duruşma, görev, müvekkil ve belge verilerinin hangi sistemde ve hangi cihazda durduğunu yazın; yedeklenmeyen bir yer bırakmayın.
2. Kayıp penceresini belirleyin. Her veri ailesi için en fazla ne kadarlık girişi yeniden yapabileceğinizi ortak avukatla birlikte yazılı olarak kararlaştırın.
3. Sıklığı pencereye göre seçin. Tarihe bağlı kritik kayıtlar için en sık, arşiv belgeleri için en seyrek düzeni kurun.
4. Yedeklemeyi otomatikleştirin. Elle alınan yedek unutulur; zamanlanmış ve hata bildirimi veren bir düzen kurun.
5. Kopyaları farklı yerlere dağıtın. Aynı cihazdaki ikinci kopya, cihaz arızasında birlikte kaybolur; en az bir kopya büro dışında ve ayrı bir ortamda dursun.
6. Geri yüklemeyi deneyin. Belirli aralıklarla bir yedeği gerçekten geri yükleyip kayıtların eksiksiz geldiğini doğrulayın.
7. Sorumlu atayın. Planın takibini üstlenen kişinin adını belirleyin ve izin dönemlerinde yerine bakacak yedeğini yazın.

Bu yedi adımın ortak noktası, kararların kişilere değil yazılı kurala bağlanmasıdır. Büroda yedeği bilen tek kişi stajyerse ve o ayrılırsa plan da onunla birlikte kaybolur. Plan ne kadar sade olursa uygulanma ihtimali o kadar yüksektir.

Uygulamada en çok zorlanılan adım ikincisidir; çünkü kayıp penceresini belirlemek, "ne kadar kayıp kabul ediyoruz" sorusuna rakamsal değil ama net bir cevap vermeyi gerektirir. İş yükü yüksek dönemlerde, örneğin adli tatil öncesi yoğunlukta, pencereyi daha dar tutmak akıllıca olur. Dönemsel yoğunluğu planın içine yazmak, o dönemde sıklığı geçici olarak artırmanızı da kolaylaştırır.

Yedeğin Saklanacağı Yer ve Kopya Sayısı

Sıklık kadar önemli olan ikinci konu, yedeğin nerede durduğudur. Yedek, canlı verinin yanında aynı cihazda duruyorsa fidye yazılımı, yangın, su baskını ya da çalınma gibi olaylarda ikisi birlikte gider. Meslek camiasında yaygın bir uygulama olarak şu üç parçalı yaklaşım kullanılır: verinin üç kopyası bulunsun, bu kopyalar iki farklı ortamda tutulsun ve en az biri büro dışında olsun. Bu bir kanun hükmü değil, pratikte işe yarayan bir ezberdir.

Fidye yazılımı konusunda özel bir dikkat gerekir. Bürodaki bilgisayara bağlı sürekli açık duran bir harici disk, zararlı yazılım şifrelemeye başladığında canlı veriyle birlikte şifrelenebilir. Bu nedenle kopyalardan birinin, normal kullanımda büro ağından doğrudan değiştirilemeyen bir konumda tutulması gerekir. Yedeğe yazma yetkisi olan hesapla günlük iş yapılan hesabın ayrılması da bu riski azaltır.

Müvekkil verisi taşıyan yedek bir kişisel veri işleme faaliyetidir ve KVKK kapsamındadır. Yedeğin şifrelenmesi, erişimin yetkili kişilerle sınırlanması ve yedeğin nerede tutulduğunun bilinmesi gerekir. Verinin yurt dışındaki bir hizmette tutulması gibi seçimler ayrıca değerlendirme gerektirir; bu konuda somut olayınıza göre hukuki görüş almanız yerinde olur.

• ✓ Kritik kayıtlar için en az üç kopya var mı?
• ✓ Kopyalar en az iki farklı ortamda mı tutuluyor?
• ✓ Bir kopya büro dışında ve ayrı bir konumda mı?
• ✓ Yedekler şifreli ve erişimi yetkili kişilerle sınırlı mı?
• ✓ Yedeğe yazma yetkisi, günlük iş hesabından ayrı mı?

Bu kontrol listesi bir denetim formu değil, yılda birkaç kez kendinize sormanız gereken soruların kısa hâlidir. Cevaplardan biri "bilmiyorum" ise plan o noktada eksiktir; bilmemek, çoğu zaman yedeğin gerçekte alınmadığının ilk işaretidir. Özellikle bulut tabanlı bir depolama kullanıyorsanız, hizmetin kendi koruma özelliklerini ve silinen verinin ne kadar süre geri alınabildiğini sağlayıcının belgelerinden okuyup plana not edin; bu bilgiyi varsaymak yerine kaynağından doğrulamak gerekir.

Geri Yükleme Testi: Yedeğin Çalıştığını Nasıl Anlarsınız?

Yedek almak, yedeğe sahip olmak demek değildir. Bozuk, eksik ya da şifresi unutulmuş bir yedek, hiç yedek olmamasından daha tehlikelidir; çünkü güven duygusu verir. Bu yüzden her planın zorunlu bir parçası, yedeğin düzenli olarak geri yüklenip kontrol edilmesidir. Bu test yapılmadığında yedeğin işe yarayıp yaramadığı, ancak veri kaybı yaşandığı anda öğrenilir.

Test için büyük bir operasyona gerek yoktur. Ayrı bir bilgisayarda ya da deneme ortamında son yedeği geri yükleyin, ardından birkaç dosyayı rastgele açın, süre ve duruşma kayıtlarının sayısını canlı sistemle karşılaştırın ve en son girilen kaydın yedekte bulunup bulunmadığına bakın. Eksik gelen kayıt varsa sıklığı da gözden geçirmeniz gerekir; çünkü eksiklik, yedeğin bazı değişiklikleri kaçırdığını gösterir.

Testi hangi aralıkla yapacağınız büronun büyüklüğüne bağlıdır; ama bir kural geçerlidir: yedekleme sisteminde veya veri yapısında büyük bir değişiklik olduğunda, ilk planlı testi beklemeden bir deneme yapın. Yeni bir yazılıma geçiş, yeni bir sunucu ya da yeni bir depolama hizmeti, eski yedekleme düzeninin hâlâ aynı kapsamı koruduğunu garanti etmez.

Testin bir başka faydası, geri yükleme süresini ölçmenizi sağlamasıdır. Yedek eksiksiz olsa bile geri yüklemesi bir iş gününü alıyorsa, büro o süre boyunca takip verisine erişemez. Bu durumda tebligatları ve duruşmaları kâğıt üzerinden ya da yedek bir yolla izleyecek geçici bir düzen de planın parçası olmalıdır. Geri yükleme süresini bir kez ölçmek, krizde alınacak kararları ciddi biçimde kolaylaştırır.

Geri yükleme kontrol notu:
Tarih: ....
Test edilen yedek: son tam yedek
Süre ve duruşma kayıtlarının sayısı canlı sistemle aynı mı: evet / hayır
Son girilen kayıt yedekte var mı: evet / hayır
Eksik varsa sıklık gözden geçirilecek, sorumlu: ....

Bu not birkaç dakikada doldurulur ve ileride bir sorun çıkarsa planın ihmal edilmediğini gösteren yazılı bir kanıt olur. Hukuk bürosunda "yedeğimiz vardı" cümlesi, "geri yüklemeyi denedik ve çalıştığını gördük" cümlesinin yanında zayıf kalır.

Süre Takibinde Bürodan Bağımsız Bir Güvence Katmanı

Yedekleme kaybı sonradan telafi eder; ama süre takibi için asıl hedef, kaybın hiç yaşanmaması ya da yaşansa bile sürelerin kaçmamasıdır. Bunu sağlamanın yollarından biri, süre ve tebligat verisini büro bilgisayarlarından bağımsız, profesyonel bir platformda tutmaktır. Bu bölüm, MÜHLET'in bu konuda hangi derde karşılık geldiğini abartmadan anlatır; yedekleme ayrıntıları bu yazının konusu değildir ve burada MÜHLET'in yedekleme düzenine dair bir taahhüt verilmemektedir.

MÜHLET, UETS'e düşen e-tebligatları tarayıcı eklentisiyle avukatın kendi bilgisayarında, kendi oturumuyla otomatik alır; şifre MÜHLET'e verilmez ve sunucular UETS'e bağlanmaz. Yapay zekâ tebligatı analiz eder, mahkeme, esas numarası, taraflar ve tebligat türünü çıkarır. Her çıktı bağımsız bir usul kuralı motoruyla doğrulanır; güven düşükse avukattan onay istenir. Süreler Türk adli takvimine göre, adli tatil, resmî tatil ve hafta sonu düzeltmeleriyle hesaplanır.

Hatırlatma, son güne kadar kademeli olarak e-posta, SMS ve uygulama ya da tarayıcı bildirimiyle yapılır. Böylece tek bir büro bilgisayarının arızası, sürelerin takibini durdurmaz; telefonunuz ve e-postanız hatırlatmayı almaya devam eder. Takvim senkronizasyonu, iOS ve Android mobil uygulama, ortak, avukat, sekreter ve stajyer rollerine göre yetki ve dava, müvekkil, duruşma ve görev yönetimi de aynı yapıda bulunur. Veriler KVKK uyumlu biçimde Türkiye'de barındırılır; sistem tebligat kredisiyle çalışır ve ilk kullanımda ücretsiz deneme kredisi verilir. Ayrıntıları MÜHLET'in tanıtım sayfasında inceleyebilirsiniz.

Özelliklerin işleyişini daha yakından görmek isterseniz süre takibi, UETS entegrasyonu, bildirim sistemi ve yapay zekâ ile tebligat analizi sayfalarına bakabilir, kullanım modelini fiyatlar sayfasından öğrenebilirsiniz. Süreyi önce kendiniz denemek isterseniz ücretsiz hukuki süre hesaplama aracı ve diğer hukuki hesaplama araçları da hazırdır.

Unutmayın: böyle bir platform, büronuzun kendi dosya ve belge yedeğinin yerini tutmaz. Dilekçe taslakları, müvekkil belgeleri ve iç yazışmalar için kendi yedekleme planınız devam etmelidir; platform, tarihe bağlı kritik verinin ikinci bir güvence katmanı olarak düşünülmelidir.

Dava Takip Verisinin Yedeklenmesinde Sık Yapılan Hatalar

Bürolarda en sık karşılaşılan hata, yedeğin var sayılmasıdır. Yedekleme yazılımı bir kez kurulur, ilk günlerde çalışır ve aylar sonra bir arıza anında yedeğin aslında çok önce durduğu anlaşılır. Disk dolmuş, parola değişmiş ya da bağlantı kopmuş olabilir; ama hata bildirimi kimseye ulaşmadığı için kimse fark etmemiştir. Çözüm, yedekleme sonucunu her gün gören bir kişi atamak ve başarısız yedekte bildirim almaktır.

İkinci yaygın hata, tek bir ortama güvenmektir. Aynı odadaki ikinci disk, yangında ya da hırsızlıkta ilk diskle birlikte gider. Üçüncüsü, yedeği yalnızca dosya sunucusuyla sınırlamaktır; oysa süre, tebligat ve duruşma kayıtlarının tutulduğu veritabanı, ayrı bir yedek kapsamı gerektirebilir. Dördüncüsü ise sıklığı veri hızından bağımsız seçmektir: her şeyi haftada bir yedeklemek hem arşiv için gereksiz hem takip verisi için yetersizdir.

Beşinci hata, ayrılan çalışanın erişiminin kapatılmamasıdır. Yedeğe yazma ya da yedekten okuma yetkisi olan eski bir stajyerin hesabı açık kalırsa hem güvenlik hem KVKK açısından risk oluşur. Altıncısı, büro içi bilginin tek kişide toplanmasıdır: yedekleme düzenini yalnızca bir kişi biliyorsa, o kişinin izinli olduğu hafta bir arıza yaşanırsa kimse ne yapacağını bilemez. Planın yazılı olması ve en az iki kişinin bunu uygulayabilmesi bu riski ortadan kaldırır.

Son olarak, yedek sıklığını bir kez belirleyip yıllarca değiştirmemek de bir hatadır. Büronuz büyüdükçe dosya sayısı, çalışan sayısı ve günlük kayıt hacmi artar; bir yıl önce yeterli olan günlük yedek bugün yetersiz kalabilir. Sıklığı yılda en az bir kez, büro büyüklüğü ve yeni kullanılan sistemlerle birlikte yeniden değerlendirmek sağlıklı bir alışkanlıktır. Bu gözden geçirmeyi büro toplantılarının bir maddesi yapmak, konunun unutulmasını önler ve yeni gelen çalışanlara da planı anlatma fırsatı verir.

Sık Sorulan Sorular

Bu yazı genel bilgilendirme amaçlıdır; somut olayınız için hukuki değerlendirme gerekir.