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.
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; 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ğini | 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ü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.
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. 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
Ü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
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. 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 verileri ne sıklıkla yedekleniyor?
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ü?
Veri taşımada kayıp riskini nasıl azaltıyorsunuz?
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, 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.
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:
