İçeriğe geç

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

Kategori
Teknoloji
Yayı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 hâlini anlatıyor (değişiklik geçmişi ve yedek saklama süreleri 23 ve 24 Eylül 2026'da, geri dönüşüm kutusu ve geri yükleme ayrıntıları 13 Ekim 2026'da güncellendi): silinen kayıt nerede durur, silinmeyip bozulan veri nereden okunur, yedek hangi ritimle alınır ve bir yedeğin gerçekten geri yüklenebildiği nasıl sorgulanır. 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, geri dönüşüm kutusu satırı 13 Ekim 2026.
KatmanNeyi kurtarırNeyi kurtarmaz
Geri dönüşüm kutusuSilinen kayıt çöp kutusuna taşınır; kutudan tek tek ya da toplu geri alma, düzenleme yetkisi olan kayıt sahibine ve tüm kayıtları düzenleme yetkisi olan kullanıcılara (yöneticiler dâhil) açıktır; bu yetkilerin hangi profilde açık olduğu kuruluma göre değişirÜ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: neyin ne zaman neye çevrildiğiniKaydı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ünlük otomatik temizlik 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 kutusuna taşınıyor. Çöp kutusundaki kayıtlar 30 gün sonra otomatik silinir. Rıza ve yasal kanıt kayıtları ile hâlâ başka kayda bağlı olanlar saklanır. Kutudan geri almayı da 23 Eylül 2026'da ürün kodunda ve canlı sistemde ölçtük: geri alma, geri dönüşüm kutusu ekranından yapılır ve düzenleme yetkisi olan kayıt sahibine ve tüm kayıtları düzenleme yetkisi olan kullanıcılara (yöneticiler dâhil) açıktır. Bu yetkilerin hangi profilde açık olduğu kuruluma göre değişir. Bu yüzden «kullanıcı kendi hatasını kendi düzeltir» cümlesini genel bir kural olarak kurmuyoruz. Kurulumunuzda bu yetkilerin kimde olduğunu keşif kapsamında birlikte çıkarıyoruz. Çöp kutusundan tek tek ya da toplu geri yükleyebilirsiniz.

Asıl mesele bu 30 günün nereden sayıldığı. Silme anından. Sunucumuzdaki yerel 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. Sunucu dışındaki şifreli yedekler ise 90 gün sonra kendiliğinden silinir. Yalnız her veritabanının en yeni 28 kopyası bu sürenin dışında kalır; ayrıntısı aşağıdaki yedekleme bölümünde.

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. Yani ne «nasılsa yedekte vardır» ne de «otuzuncu günden sonra kesin gitti» cümlesini kurabiliyoruz. Web, mobil, API, MCP ve Rapi üzerinden yapılan her kayıt silme işlemi, kaydı geri dönüşüm kutusuna taşır. 1 Ekim 2026 itibarıyla yetkili kullanıcı kutudaki kayıtları kalıcı olarak silebilir; kanıt ve rıza kayıtları kalıcı silmeye karşı korunur. Kayda bağlı dosyalar (ör. özgeçmişler) ise, dosyayı kayıt kartından ya da kaydı silseniz de depolama alanından (DigitalOcean Spaces, Frankfurt) silinmez; ürün bu dosyaları bugün kendiliğinden silmiyor. Silinmeleri için destek ekibimize yazmanız gerekir.

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; 30 gün dolduğunda kayıt kutudan otomatik silinir.

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: mevcut bir kayıtta bir alanın değeri değiştiğinde (toplu güncelleme ve içe aktarmanın güncelleme modu dâhil) eski değer, yeni değer ve değişikliğin zamanı kaydın üstünde saklanır; korumalı alanlarda değerler yerine yalnız bir işaret tutulur. Kaydın ilk oluşturulması (içe aktarmayla ya da API ile yeni oluşturulan kayıtlar dâhil), birleştirmede alt kayıtların taşınması ve sistemin arka planda yaptığı bazı toplu güncellemeler bu geçmişe girmez. İz otomatik olarak silinmez.

İ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 veritabanı tablosudur ve yumuşak silme sütunları vardır. Veritabanında doğrudan yapılan yazımlar bu ize girmez ve ekibimiz, destek talebi üzerine bir kaydın geçmiş satırlarını veritabanından silebilir; ürün içinde bunu yapan bir kullanıcı yolu yok. Denetim izini kurcalanamaz bir kanıt gibi anlatmıyoruz, çünkü ölçüm bunu göstermiyor.

Yedekleme: altı saatlik ritim, yerelde 30 günlük raf ve arada kalan pencere

Yedekler altı saatte bir alınır. Sunucumuzdaki yerel yedekler 30 gün saklanır ve sonra kendiliğinden silinir; sunucu dışındaki şifreli yedekler ise 90 gün sonra otomatik olarak silinir. Bu 90 günlük süre, yedekleme durur ya da bozulursa son kopyalar da silinmesin diye her veritabanının en yeni 28 kopyasını yaşından bağımsız olarak tutar. Altı saatte bir yedeklenen etkin bir hesapta 28 kopya yaklaşık bir haftalık yedeğe karşılık geldiği için o hesapta pratikte 90 günlük süre işler; hesabı sonlandırılan bir müşterinin veritabanına ait son 28 kopya ise bu süreyle silinmez ve onları silen ayrı bir adım bugün yok. 20 Ağustos 2026 ölçümünde Rapitek CRM sunucusundaki yedekleme kümesinin çıktısı Almanya'daki (Falkenstein) ayrı bir depolama alanına kopyalanıyordu. 23 Eylül 2026 ölçümüne göre her yedekte dökümün hatasız tamamlandığı ve sıkıştırılmış dosyanın açılabildiği denetleniyor. 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 bölümdeki yedekleme bilgisi veritabanlarını kapsıyor. Yüklenen dosyalar, ekler, görseller, ses kayıtları, veritabanının dışında ayrı bir depoda durur.

Geri dönüş testi: sağlayıcıya hangi soru sorulur?

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 bir sonuç yoksa bir ölçüm değil bir niyet beyanıdır.

Bir sağlayıcı size «yedeklerimizi düzenli olarak test ediyoruz» diyorsa sorulacak soru şudur: en son ne zaman, neyi kapsadı ve sonuç neydi? Bu sorulara somut cevap veremeyen bir test, yapılmamış sayılır.

Rapitek CRM'deki cevap: yedekler 6 saatte bir alınır, şifreli kopyası ayrı bir konumda tutulur. Geri yükleme elle yapılan tatbikatlarla doğrulanır; son tatbikat 6 Ekim 2026.

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. Kutudan geri alma, düzenleme yetkisi olan kayıt sahibine ve tüm kayıtları düzenleme yetkisi olan kullanıcılara (yöneticiler dâhil) açıktır; bu yetkilerin sizin profilinizde açık olup olmadığını kurulumunuzda 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 ve zamanı gösterir. Doğru değeri buradan okuyup kaydı düzeltirsiniz; değişikliğin zamanı, bozulmanın kaynağını bulmaya da yardım eder. İlk oluşturma, birleştirmede alt kayıt taşıma ve bazı arka plan güncellemeleri bu izde görünmez.

  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. 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.

Müşteri adayından teklife, faturadan göreve CRM'deki kayıtlar REST API ile okunup yazılır; alan yapısı da dışarıdan görülür. Ölçtüğümüz şey bu erişimin 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.

Kapsam ve kurulum koşulları

  • Yedekler arasındaki değişiklikleri kurtaran bir noktaya-dönüş mekanizması ölçüm tablomuzda yok; altı saatlik pencereyi kapattığımızı söylemiyoruz.
  • Bu yazıdaki yedekleme bilgisi veritabanlarını kapsıyor; yüklenen dosyalar ayrı bir depoda durur.
  • Geri yükleme için bir süre taahhüdü vermiyoruz.
  • İçe aktarmada biçim ve zorunlu alan hataları sık görülür; bu yüzden aktarımı canlıya geçmeden önce deneme verisiyle birlikte test ediyoruz.
  • Yazılı bir çalışma süresi (SLA) taahhüdü vermiyoruz.

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 bekler. Çöp kutusundaki kayıtlar 30 gün sonra otomatik silinir. Rıza ve yasal kanıt kayıtları ile hâlâ başka kayda bağlı olanlar saklanır. Kutudan geri alma, düzenleme yetkisi olan kayıt sahibine, yöneticilere ve tüm kayıtları düzenleyebilenlere açıktır; yetkiler kuruluma göre değiştiğinden buna herkesin yapabileceği bir adım demiyoruz. Yerel 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. Kutudan tek tek ya da toplu geri yükleyebilirsiniz; kalıcı silmeyi ise yetkili kullanıcı kutudan kendisi yapabilir. 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 Rapitek CRM sunucusundaki yedekleme kümesinin çıktısı Almanya'daki (Falkenstein) ayrı bir depolama alanına kopyalanıyordu. Ritim ve raf ömrü şöyle: yedekler altı saatte bir alınır; sunucumuzdaki yerel yedekler 30 gün saklanır, sunucu dışındaki şifreli yedekler ise 90 gün sonra kendiliğinden silinir; yalnız her veritabanının en yeni 28 kopyası yaşına bakılmadan tutulur: sonlandırılan hesabın son 28 kopyasını bu süre silmez, silen başka adım da bugün yok.
Kayıt silinmedi ama yanlış değiştirildi. Eski değeri görebilir miyim?
Evet, alan bazlı değişiklik geçmişinden: mevcut bir kayıtta bir alan değiştiğinde (toplu güncelleme dâhil) eski değer, yeni değer ve zaman kaydın üstünde saklanır; korumalı alanlarda değerler yerine yalnız bir işaret tutulur. Kaydın ilk oluşturulması (içe aktarmayla oluşturma dâhil), birleştirmede alt kayıtların taşınması ve sistemin bazı arka plan güncellemeleri bu geçmişe girmez. İz otomatik olarak silinmez. İki sınırı daha 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 veritabanı tablosudur: doğrudan veritabanı yazımları bu ize girmez ve ekibimiz destek talebi üzerine bir kaydın geçmiş satırlarını silebilir.
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üş.
Veri taşımada kayıp riskini nasıl azaltıyorsunuz?
İçe aktarmada biçim ve zorunlu alan hataları sık görülür; bu yüzden aktarımı canlıya geçmeden önce deneme verisiyle birlikte test ediyoruz.
Veri kaybı yaşarsak ne kadar sürede geri yüklersiniz?
Bir süre taahhüdü vermiyoruz. Ayrıca yazılı bir çalışma süresi (SLA) taahhüdü vermiyoruz. 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, kurucumuzun 200'den fazla Salesforce projesindeki deneyimiyle kuruldu. Ürün yeni, deneyim değil: alanları, aşamaları ve raporları biz yapılandırıyoruz, verinizi biz aktarıyoruz, ekibinize Türkçe eğitimi biz veriyoruz. Ardından 7 günlük deneme hesabınızı açalım; kredi kartı istemiyoruz.

Yazan

Kerim Yıldırım

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

RapitekGO ile yapıldı

Ölçüm için isteğe bağlı çerez kullanmak istiyoruz; reddederseniz site aynen çalışır. Çerez politikası