CRM'de Silinen Kayıt Geri Gelir mi? Çöp Kutusu, Yedekleme ve Geri Dönüş Testi
Bir kullanıcı yanlış satırı seçti ve sildi. Ya da bir toplu güncelleme yanlış filtreyle çalıştı ve üç yüz firmanın adres alanının üstüne başka bir sütun yazıldı. İki durumda da ilk soru aynı: geri gelir mi?
Bu sorunun tek bir cevabı yok, çünkü «geri getirmek» birbirinden bağımsız birkaç mekanizmanın ortak adı. Her biri farklı bir kaybı kurtarır, farklı bir zaman penceresinde çalışır ve farklı kişi tarafından başlatılır. Bunları tek torbaya koymak, yazılım alırken ayırt etmeyen bir soru sordurur: «Yedekleme var mı?» Ayırt eden soru bu değil; o yedekten dönüşün neyi geri getirdiği, neyi geri getiremediği ve dönüşü kimin işini geri alarak yapacağınız.
Bu yazı, Rapitek CRM'de bu katmanların 20 Ağustos 2026 ölçümüyle bugünkü hâlini anlatıyor: silinen kayıt nerede durur, silinmeyip bozulan veri nereden okunur, yedek hangi ritimle alınır, o yedeğin gerçekten okunabildiğini kim sınadı ve o sınama neyi kapsamadı. Ölçmediğimiz yerleri de yazıyoruz — sayısı olmayan bir vaat burada bulamayacaksınız.
Yedeğin var olması bir cevap değil. Asıl soru şu: o yedekten dönüş neyi geri getirir, neyi geri getiremez ve dönüş kararını kimin işini geri alarak vermiş olursunuz?
İçindekiler
Veri kaybı tek bir olay değil, en az dört ayrı olay
Kayıp derken kastedilen şey her seferinde başka. Ayırt edilmesi gereken en az dört durum var ve her birinin kurtarıcısı ayrı bir katman.
Kayıt silindi. Listede yok. Kurtarıcısı geri dönüşüm kutusu.
Kayıt duruyor ama içindeki değer yanlış. Üstüne yazıldı. Silinen bir şey olmadığı için çöp kutusunda aranacak bir şey de yok; bakılacak yer değişiklik geçmişi.
Toplu bozulma. Tek bir kayıt değil, bir nesnenin binlerce satırı birden etkilendi. Burada tek tek düzeltmek gerçekçi olmaktan çıkar ve konuşma yedeğe gelir.
Donanım arızası. Disk öldü. Bunun insan hatasıyla hiçbir ilgisi yok ve kurtarıcısı da bambaşka bir katman.
Aşağıdaki tablo bu katmanların her birinin neyi kurtardığını ve — asıl önemlisi — neyi kurtarmadığını gösteriyor. İkinci sütun kadar üçüncü sütuna da bakın; satın alma görüşmelerinde konuşulmayan sütun odur.
Hangi katman neyi kurtarır, neyi kurtarmaz?
| Katman | Neyi kurtarır | Neyi kurtarmaz |
|---|---|---|
| Geri dönüşüm kutusu | Silinen kayıt çöp kutusuna taşınır; geri alma yetkisinin kimde olduğunu ölçmedik | Üstüne yazılmış bir alan değerini: silinen bir şey olmadığı için kutuda görünmez |
| Değişiklik geçmişi (denetim izi) | Bir alanın eski değerini: kim, ne zaman, neyi neye çevirdi | Kaydın tamamının geçmiş bir andaki hâlini: iz alan alan okunur, kaydın tümü olarak değil |
| Veritabanı yedeği | Veritabanının bir andaki tam hâlini | Son yedekten sonra yapılan işleri |
| RAID1 disk aynası | Bir diskin donanım olarak arızalanmasını | İnsan hatasını: silme işlemi aynanın iki tarafına da aynı anda yazılır |
| Kendi kopyanız (API ile dışa aktarım) | Sağlayıcıdan bağımsız, sizin tarafınızda duran bir kopyayı | Kopyayı almadığınız aradaki değişiklikleri |
Geri dönüşüm kutusu: 30 gün ve o 30 günün nereden sayıldığı
Silinen kayıt veritabanından anında kalkmıyor. Yumuşak silmeyle işaretleniyor ve geri dönüşüm kutusunda 30 gün duruyor. Ölçtüğümüz şey bu: kaydın kutuda durduğu ve orada 30 gün kaldığı. Kutudan geri almanın hangi arayüzden yapıldığını ve hangi profillerde açık olduğunu ölçmedik — bu yüzden «kullanıcı kendi hatasını kendi düzeltir» cümlesini kurmuyoruz. Kurulumunuzda bu yetkinin kimde olduğunu keşif kapsamında birlikte çıkarıyoruz.
Asıl mesele bu 30 günün nereden sayıldığı. Silme anından. Veritabanı yedeklerinin saklama süresi de 30 gün — aynı sayı, ama aynı şeyi ölçmüyorlar: biri kaydın silinme anından, diğeri yedeğin alınma anından sayıyor.
Bu farkın sonucunu yumuşatmadan yazmak gerekiyor, çünkü kolayca ters okunuyor. İki pencere aynı gün kapanmaz; farklı anlardan sayıldıkları için «30. günde iki kapı birden kapanır» diye bir tarih yok. Ama bunun tersini de elimizde bir ölçüme dayandıramıyoruz: kutu penceresi dolduğunda satırın veritabanından gerçekten kalkıp kalkmadığını, kalkıyorsa o tarihten sonra alınan yedeklerin kaydı hâlâ taşıyıp taşımadığını ölçmedik. Ölçüm tablomuzda bu satır yok. Yani ne «nasılsa yedekte vardır» ne de «otuzuncu günden sonra kesin gitti» cümlesini kurabiliyoruz.
Okur açısından güvenli olan tek sonuç şu: bir silme fark edildiğinde beklemeye değmez. Kayıt kutuda dururken geri getirmek en ucuz seçenektir; kutu penceresi kapandıktan sonra elinizde ne kaldığı ölçülmemiş bir sorudur ve bir kurtarma planı ölçülmemiş bir sorunun üstüne kurulmaz.
Silinmedi, bozuldu: değişiklik geçmişi ve onun iki sınırı
Silme, kaybın yalnız bir biçimi. Diğeri daha sessiz: kayıt yerinde duruyor, listede görünüyor, ama içindeki değer yanlış. Toplu güncelleme yanlış filtreyle koştu; bir içe aktarma yanlış sütunu eşledi; bir kullanıcı doğru kaydın yanlış alanına yazdı. Bu kayıp fark edilene kadar aylar geçebilir, çünkü ekranda eksik bir şey yoktur.
Bu durumda çöp kutusunun yapacağı bir şey yok. Bakılacak yer alan bazlı değişiklik geçmişidir: bir alanın değeri değiştiğinde eski değer, yeni değer, değişikliği yapan kullanıcı ve zamanı kaydın üstünde saklanır. Erişebildiğimiz sekiz kurulumda bu iz Nisan 2026'dan bu yana 213.928 alan değişikliği taşıyor ve otomatik olarak silinmiyor.
İki sınırını da yazalım, çünkü ikisi de alıcının kararını değiştirir.
Birincisi: bu bir geri alma düğmesi değil. Eski değeri görürsünüz; geri yazmak elle yapılan bir iştir. Üç kayıtta kolay, üç bin kayıtta bir iş kalemidir.
İkincisi: bu iz «değiştirilemez» değildir. Sıradan bir tablodur ve yumuşak silme sütunları vardır; erişebildiğimiz sekiz kurulumdaki 19 profilin 19'unda da silme yetkisi açıktır. Denetim izini kurcalanamaz bir kanıt gibi anlatmıyoruz, çünkü ölçüm bunu göstermiyor.
Yedekleme: altı saatlik ritim, 30 günlük raf ve arada kalan pencere
Yedekler altı saatte bir alınır ve 30 gün saklanır. 20 Ağustos 2026 ölçümünde yedekleme kümesinde 45 veritabanı vardı, iş bütünlük testli çalışıyordu ve çıktı Almanya'daki (Falkenstein) ayrı bir depolama alanına kopyalanıyordu. Bu bir ölçüm gününün fotoğrafı: koşumlar arasındaki tutarlılığı, yani her koşumun bütünlük kontrolünden geçtiğini ayrıca ölçmedik. Diğer bileşenlerin şehir kırılımı güvenlik sayfasında.
Bu ritmin iki sonucu var ve ikisi de alıcının duyması gereken cinsten.
Bir: arada bir pencere kalır. Tam bir veritabanı geri yüklemesi, son yedekten sonra yapılmış hiçbir değişikliği geri getirmez; bu pencere altı saate kadar çıkar. Yedekler arasındaki değişiklikleri kurtaran bir noktaya-dönüş mekanizması ölçüm tablomuzda yok, dolayısıyla o pencereyi kapattığımızı söylemiyoruz.
İki: yedekten dönüş seçici değildir. Geri yüklenen şey tek bir kayıt değil, veritabanının bir andaki tam hâli. Silinmiş bir firmayı tam dönüşle geri getirmek, aynı veritabanında çalışan herkesin son yedekten beri yaptığı işi silmek demektir. Tam dönüş bu yüzden ilk çare değil son çaredir; geri dönüşüm kutusu da tam bu yüzden vardır.
Bir kapsam notu daha: bu ölçüm veritabanlarını kapsıyor. Yüklenen dosyalar — ekler, görseller, ses kayıtları — veritabanının dışında ayrı bir depoda durur ve ölçüm tablomuzda o deponun yedeklenmesine ait bir satır yok. Yani «dosyalarınız da altı saatte bir yedekleniyor» cümlesini kuracak ölçümümüz bulunmuyor.
Geri dönüş testi: yedeğin okunabildiğini kim, ne zaman ölçtü?
Yedek almak bir şey, o yedeğin gerçekten geri yüklenebildiğini bilmek başka şey. Aradaki farkı kapatan tek şey denemektir; ve «yedeklerimizi test ediyoruz» cümlesi, arkasında bir tarih ve iki sayı yoksa bir ölçüm değil bir niyet beyanıdır.
Bizim elimizdeki ölçüm tek bir olay: 19 Ağustos 2026'da bir müşteri veritabanı geçici bir şemaya geri yüklendi. 239 tablonun 239'u geldi ve satır sayıları birebir tuttu — 438.817 satıra karşılık 438.817 satır.
Şimdi bu cümlenin sınırını çizelim, çünkü sınırı çizilmemiş bir kanıt kanıt değildir.
Bu bir tatbikat programı değil, tek bir olay. «Düzenli geri dönüş tatbikatı yapıyoruz» demiyoruz; bunu gösterecek ikinci bir ölçümümüz yok. Test bir dökümün yüklenebildiğini ve tablo ile satır sayılarının tuttuğunu gösterdi. Üretim ortamına dönüşün ne kadar süreceğini ölçmedi, yüklenen dosyaların geri dönüşünü kapsamadı ve bir müşteri talebiyle koşmadı.
Bunu neden bu kadar daraltarak yazdığımızı da söyleyelim: bir sağlayıcı size «yedeklerimizi düzenli olarak test ediyoruz» diyorsa sorulacak soru şudur — en son ne zaman, kaç tablo, kaç satır ve sonuç neydi? Bu dört soruya sayı ile cevap veremeyen bir test, yapılmamış sayılır.
Bir kayıt kaybolduğunda sırayla ne yapılır
-
1
Ayırt edin: silindi mi, üstüne mi yazıldı?
Kayıt listede hiç yoksa silme, kayıt duruyor ama değeri yanlışsa üstüne yazma söz konusudur. İkisi ayrı katmandan kurtarılır; yanlış katmanda aramak yalnız zaman kaybettirir.
-
2
Silindiyse geri dönüşüm kutusuna bakın ve beklemeyin
Silme fark edildiği gün bakılacak ilk yer burasıdır. Geri alma yetkisinin sizin profilinizde açık olup olmadığını ölçmedik; kurulumunuzda bunu birlikte kontrol edin.
-
3
Üstüne yazıldıysa kaydın değişiklik geçmişini açın
Alan bazlı iz eski değeri, yeni değeri, değiştiren kullanıcıyı ve zamanı gösterir. Doğru değeri buradan okuyup kaydı düzeltirsiniz; iz aynı zamanda bozulmanın hangi işlemden geldiğini de söyler.
-
4
Sonuç alamadıysanız kapsamı yazın: hangi nesne, hangi tarih aralığı, kaç kayıt
Yedek konuşması ancak bu üç bilgiyle başlar. Kapsam bilinmeden dönüşün maliyeti hesaplanamaz, çünkü maliyet kaybın büyüklüğüne değil dönüşün kimi geri alacağına bağlıdır.
-
5
Tam veritabanı dönüşünü son çare olarak değerlendirin
Bu kararı tek bir kaydın değeriyle değil kaybın kapsamıyla verin. Kapsam bu adıma gelecek kadar büyükse, kararı vermeden önce aynı veritabanını kullanan ekiplere yazılı olarak haber verin.
RAID yedek değildir — ve sizde duran bir kopya beşinci katmandır
Ölçtüğümüz sunucuda RAID1 kurulu iki NVMe disk var; işletim sistemi Ubuntu 24.04 LTS. Bu tek bir makinenin ölçümü — aynı kurulumu bütün sunucular için ölçmedik, o yüzden bunu altyapının tamamına mal etmiyoruz. Yüklenen dosyaların durduğu ayrı depo da bu ölçümün dışında. RAID1 bir diskin donanım olarak ölmesine karşı çalışır ve yalnızca ona karşı çalışır. Yanlışlıkla silinen bir kayıt aynanın iki tarafına da aynı anda yazılır; ayna, hatayı da eş zamanlı kopyalar. RAID bir yedek değildir ve ölçüm tablomuzda ayrı bir satır olarak durmasının sebebi de budur.
Bir katman daha var ve o tamamen sizin tarafınızda: verinizin sağlayıcıdan bağımsız, sizde duran bir kopyası. Bu kopya yukarıdaki dört katmanın hiçbirinin yerini tutmaz — ama dördü de aynı anda işe yaramadığında elinizde kalan tek şey odur.
Ürün kutudan 183 iş nesnesiyle geliyor ve her biri REST API'de kendi veri ve şema ucuyla yayımlanıyor — alan yapısını describe ile dışarıdan okuyabilirsiniz. Ölçtüğümüz şey bu uçların var olduğu ve dışarıdan kullanıldığı; düzenli bir dışa aktarımı sizin adınıza kurduğumuzu iddia etmiyoruz. Böyle bir kopyayı istiyorsanız bunu keşif kapsamına yazmak gerekir.
Bizim sınırlarımız
- Yedekler şifrelenmiyor. Bu bir ölçüm boşluğu değil, ölçülmüş bir hayır: yedek, bir veritabanı dökümünün sıkıştırılmış hâli olarak alınıyor ve şifresiz duruyor. «Yedekleriniz şifreli saklanır» demiyoruz.
- Yedekler arasındaki değişiklikleri kurtaran bir noktaya-dönüş mekanizması ölçüm tablomuzda yok; altı saatlik pencereyi kapattığımızı söylemiyoruz.
- Yüklenen dosyaların yedeklenmesine ait bir satır ölçüm tablomuzda yok; yedekleme ölçümü veritabanlarını kapsıyor.
- Geri yükleme için bir süre taahhüdü vermiyoruz — ölçtüğümüz tek dönüş olayının süresi kayıtlı değil.
- Sıfır veri kaybı garantisi vermiyoruz: erişebildiğimiz 8 kiracıda ölçtüğümüz 34 içe aktarma işinin 16'sı başarısız oldu.
- Yazılı bir çalışma süresi (SLA) taahhüdü vermiyoruz; kiracı adreslerini dışarıdan izleyen bağımsız bir servis kurulu değil.
Sık sorulan sorular
CRM'de silinen bir kayıt geri gelir mi?
Rapitek CRM verileri ne sıklıkla yedekleniyor?
Yedekleriniz şifreli mi saklanıyor?
Yedekten geri dönüşü hiç denediniz mi?
Kayıt silinmedi ama yanlış değiştirildi — eski değeri görebilir miyim?
Tek bir kaydı geri getirmek için yedekten dönmek mümkün mü?
Sıfır veri kaybı garantisi veriyor musunuz?
Veri kaybı yaşarsak ne kadar sürede geri yüklersiniz?
İlgili içerikler
- Güvenlik — veri konumu, şifreleme ve erişim katmanının ölçülmüş hâli.
- SaaS nedir — bir yazılımı kiralamanın veri üzerindeki sonuçları.
- Satış hattı (pipeline) nedir — kayıt geçmişinin satış tahmininde ne işe yaradığı.
- Rapitek CRM ürün sayfası — nesneler, denetim izi ve API yüzeyi.
Kayıp senaryonuzu ekranda birlikte geçelim
Rapitek CRM'i kuran ekip, Salesforce döneminde 200'den fazla kurumsal CRM projesi tamamladı. Ürün yeni, ekip değil: alanları, aşamaları ve raporları biz yapılandırıyoruz, verinizi biz aktarıyoruz, ekibinize Türkçe eğitimi biz veriyoruz.
Keşifte saklama ve geri dönüş beklentinizi yazılı kapsama alırız; hangi katmanın hangi kaybı kurtardığını ekranda birlikte geçeriz.
Kerim Yıldırım
Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi
Kaynaklar
Bu yazıdaki dış olgular şu birincil kaynaklara dayanıyor:
