İçeriğe geç

CRM'de Silinen Kayıt Geri Gelir mi? Çöp Kutusu, Yedekleme ve Geri Dönüş Testi

Kategori TeknolojiYayın tarihi 24 Ağustos 2026

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.

Geri dönüş
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?

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.

Kurtarma katmanları

Hangi katman neyi kurtarır, neyi kurtarmaz?

Rapitek CRM'de ölçülmüş hâliyle; ölçüm tarihi 20 Ağustos 2026.
KatmanNeyi kurtarırNeyi kurtarmaz
Geri dönüşüm kutusuSilinen 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 çevirdiKaydın tamamının geçmiş bir andaki hâlini: iz alan alan okunur, kaydın tümü olarak değil
Veritabanı yedeğiVeritabanının bir andaki tam hâliniSon 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.

Sıralı yordam

Bir kayıt kaybolduğunda sırayla ne yapılır

  1. 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. 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. 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. 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. 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'de silinen kayıt veritabanından anında kalkmaz: yumuşak silmeyle işaretlenir ve geri dönüşüm kutusunda 30 gün durur. Ölçtüğümüz şey bu pencerenin varlığı; kutudan geri alma yetkisinin hangi profillerde açık olduğunu ölçmedik, o yüzden bunu kullanıcının kendi başına tamamlayabileceği bir adım diye anlatmıyoruz. Pencere kapandıktan sonrası için de bir güvence vermiyoruz. Veritabanı yedekleri 30 gün saklanır, ama bu süre kaydın silinme anından değil yedeğin alınma anından sayılır — yani iki pencere aynı gün kapanmaz. Kutu penceresi dolduğunda satırın veritabanından kalkıp kalkmadığı ve sonraki yedeklerde durup durmadığı ölçüm tablomuzda yok. Pratik sonuç: silmeyi fark ettiğiniz gün harekete geçin.
Rapitek CRM verileri ne sıklıkla yedekleniyor?
20 Ağustos 2026 ölçümünde yedekleme kümesinde 45 veritabanı vardı; iş bütünlük testliydi ve çıktı Almanya'daki (Falkenstein) ayrı bir depolama alanına kopyalanıyordu. Ritim ve raf ömrü şöyle: yedekler altı saatte bir alınır ve 30 gün saklanır. Bunun bir ölçüm gününün fotoğrafı olduğunu da yazalım — her koşumun bütünlük kontrolünden geçtiğini gösterecek, koşumlar arası bir ölçümümüz yok.
Yedekleriniz şifreli mi saklanıyor?
Hayır — ve 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; ölçüm bunu açıkça gösterdi. Bu yüzden «yedekleriniz şifreli saklanır» cümlesini kurmuyoruz. Aktarımda şifreleme ayrı bir başlıktır ve oradaki ölçümler güvenlik sayfasında. Yedek şifrelemesi bugün elimizde olmayan bir şey; olduğu gün burada yazacağız.
Yedekten geri dönüşü hiç denediniz mi?
Bir kez, ölçülmüş hâliyle: 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ısı birebir tuttu — 438.817 satıra karşılık 438.817 satır. Bunu düzenli bir tatbikat programı diye anlatmıyoruz, çünkü ikinci bir ölçümümüz yok. Test bir dökümün yüklenebildiğini ve sayıların tuttuğunu gösterdi; üretim ortamına dönüşün ne kadar süreceğini ölçmedi ve yüklenen dosyaların geri dönüşünü kapsamadı.
Kayıt silinmedi ama yanlış değiştirildi — eski değeri görebilir miyim?
Evet, alan bazlı değişiklik geçmişinden: bir alan değiştiğinde eski değer, yeni değer, değiştiren 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 silinmiyor. İki sınırı var: bir geri alma düğmesi değildir, doğru değeri okuyup geri yazmak elle yapılır; ve bu iz değiştirilemez değildir — sıradan bir tablodur, erişebildiğimiz sekiz kurulumdaki 19 profilin 19'unda da silme yetkisi açıktır.
Tek bir kaydı geri getirmek için yedekten dönmek mümkün mü?
Teknik olarak mümkün. Ama bedeli mekanik bir sebeple büyür: yedekten dönüş seçici değildir, geri yüklenen şey tek bir kayıt değil veritabanının bir andaki tam hâlidir. Tek bir firmayı geri getirmek için tam dönüş yapmak, aynı veritabanında çalışan herkesin son yedekten beri yaptığı işi geri almak demektir. Bu yüzden sıra şudur: önce geri dönüşüm kutusu, sonra değişiklik geçmişi, en sonda tam dönüş.
Sıfır veri kaybı garantisi veriyor musunuz?
Hayır. Garanti hukuki bir taahhüttür ve elimizdeki ölçüm bunu desteklemiyor. Bu konudaki en yakın sayımız şu: erişebildiğimiz 8 kiracıda ölçtüğümüz 34 içe aktarma işinin 16'sı başarısız oldu. Bu sayı bizim aleyhimize ve tam da bu yüzden yazıyoruz; ölçmediğimiz bir güvenceyi satmak, ölçtüğümüz bir sınırı yazmaktan daha pahalıya mal olur.
Veri kaybı yaşarsak ne kadar sürede geri yüklersiniz?
Bir süre taahhüdü vermiyoruz, çünkü ölçmedik: ölçülmüş tek geri yükleme olayı geçici bir şemaya yapıldı ve süresi kayıtlı değil. Ayrıca 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üre yerine söyleyebileceğimiz şey şu: talebi ürünü kuran ve geliştiren ekip alır, arada bir çağrı merkezi katmanı yoktur. Keşif görüşmesinden sonra size aralık değil tarih veririz.

İlgili içerikler

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.

Yazan

Kerim Yıldırım

Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi

RapitekGO ile yapıldı

Ziyaretinizi ölçmek için isteğe bağlı çerez kullanmak istiyoruz. Reddederseniz site aynen çalışır. Çerez politikası