Geçen ay, 2025 Ocak’ın ortasında, Kadıköy’deki masamda kahvemi yudumlarken aklıma tatsız bir soru geldi: “Bu Claude Code düzenini yarın dizüspek çok bozulursa nasıl geri getiririm?” Hani insan her şey yolundayken durup en kötü senaryoyu düşünür ya… İşte tam o an. Ve açık konuşayım — cevap hiç iç açıcı değildi.
Bir süredir Claude Code’u yoğun kullanıyorum. Global kurallar, proje bazlı hafıza notları, özel komutlar, MCP ayarları, planlar (ciddiyim). Kısacası güzel bir küçük evren kurmuşum. Sonra fark ettim ki bu evrenin kapısı tek bir cihaza kilitli. O cihaz giderse — laptop suya düşer mi, anakart yanar mı, çalınır mı — geçmiş olsun demek.
Neden kimse buna yeterince dikkat etmiyor?
İnanın, İşin aslı şu: çoğu geliştirici Claude Code gibi araçların arka planda ne kadar çok dosya oluşturduğunu bilmiyor. Ben de bilmiyordum başta. Editör masasında bu konuyu görünce hemen test etmek istedim; Beşiktaş’taki ofiste iki farklı projede denedim. Sistemin ne kadar sessiz çalıştığını görünce bayağı şaşırdım açıkçası. Araç konuşmuyor ama yazıyor, kaydediyor — unutuyor sanıyorsun, meğer kendi hafızasını yavaş yavaş örüyormuş.
Şöyle söyleyeyim, Bu durum küçük bir startup için can sıkıcı, kurumsal ekipler için biraz daha büyük dert. Startup tarafında tek kişinin makinesi gidince bilgi uçuyor. Kurumsalda ise kişi değişiyor, repo değişiyor, proje dağılıyor; sonra “Bu kuralı kim yazmıştı?” diye toplantı odasında boş boş bakışmalar başlıyor. Klasik teknoloji trajedisi. Tam da öyle.
Ben 2024’ün sonlarında bir müşterinin kurulumunu gözden geçirirken benzer bir tabloyla karşılaştım: üç farklı proje klasörü içinde dağılmış ayarlar vardı ve kimse bunların toplam hacmini bilmiyordu. Manuel yedekleme önersem kimsenin uzun süre devam ettiremeyeceğini biliyordum zaten —. Sorun sadece teknik değil, disiplin sorunu da var işin içinde.
Ayarlar nerelere saçılıyor?
Bak şimdi, mesele biraz kirli. Veri tek kutuda değil çünkü. Tipik yapı şöyle dağılabiliyor: global Claude klasörü var, proje klasörünün içinde ayrı bir.claude yapısı var, bazı şeyler memory olarak tutuluyor, bazıları rules içinde yaşıyor. Üstüne bir de encoded path’lerle saklanan proje bazlı kayıtlar eklenince — resmen mini labirent çıkıyor ortaya.
Hmm, bunu nasıl anlatsamdı… Daha fazla bilgi için Manticore Search’ü Grafana ile Tek Komutla İzle yazımıza bakabilirsiniz. Python Paketlerinde Gizli Regex Tehlikesi: 20 Kütüphane Ne Gösterdi? yazımızda bu konuya da değinmiştik.
~/.claude/
├── CLAUDE.md
├── settings.json
├── memories/
├── skills/
├── rules/
├── plans/
└── projects/
~/myproject/.claude/
├── CLAUDE.md
├── settings.json
├── skills/
└── rules/Şöyle söyleyeyim, Buna benzer yapıyı ilk kez kendi makinemde gördüğümde — Ankara’ya gittiğim Nisan 2024 gezisinde, otel Wi-Fi’si üzerinden bağlanırken — “Tamam” dedim, “bu iş artık sıradan yedekleme ile olmaz.” Kullanıcı gözüyle baktığınızda birkaç dosya gibi duruyor. Ama pratikte onlarca, hatta yüzlerce parça oluyor.
Kaldı ki Claude Code yalnızca metin bırakmıyor; çalışma alışkanlıklarını da topluyor bir anlamda. Hangi projede hangi davranışı tercih ettiğinizi öğrenen bir memory katmanı düşünün — bildiğiniz not defteri, ama sayfaları cebinizde taşıyorsunuz ve cebiniz delinirse notlar uçup gidiyor.
Sessiz büyüme problemi
Beni en çok şaşırtan şey şuydu. Kullanıcı hiçbir şey yapmasa bile sistem yeni dosyalar üretebiliyor ya da mevcutları güncelliyor olabiliyor. Yani siz “ben zaten ellemedim ki” diyorsunuz, ama arka planda ortam dolmaya devam ediyor.
Bu yüzden konu sadece yedek almak değil; süreklilik. Bugün bir şeyi kurtarmak yetmiyor — gelecek hafta da aynı güveni vermesi gerekiyor. Yapay Zekâ Yığını: Kendi Akıllı Uygulamanı Kur yazımızda bu konuya da değinmiştik.
Neyi korumak gerekiyor?
Burada önemli nokta şu: yalnızca CLAUDE.md dosyasını kopyalamak yetmiyor. Güzel olurdu, ama gerçek hayat öyle işlemiyor maalesef. Hafızalarınız var, kurallarınız var, agent tanımları var, planlarınız var; MCP ayarları ayrı bir dert… Bu ne anlama geliyor? Hepsi birbirine bağlı çalışıyor ve biri eksik olunca diğerleri tam tad vermiyor.
| Bileşen | Neden önemli? | Kayıp olursa ne olur? |
|---|---|---|
| Memories | Proje bağlamını hatırlar | Kodlama tarzınız sıfırlanır |
| Rules | Davranış sınırlarını belirler | Tutarsız çıktılar artar |
| MCP configs | Dış servis bağlantıları sağlar | Araç zinciri kopabilir |
Peki en sinir bozucu taraf ne? Çalışan iyi bir sisteminiz varken ufak bir silme işlemiyle bütün dengeyi bozabiliyorsunuz. Ben bunu geçen sene Eylül ayında İzmir’deki kısa bir uzaktan çalışma dönemimde yaşadım; yanlışlıkla test dizinini temizlerken beklediğimden fazla yapı gitmişti. Geri dönüş gerçekten uğraştırmıştı. RAG’de Asıl Kahraman Retrieval: LLM Sadece Ses Veriyor yazımızda da bu konuya değinmiştik. Claude Kendi Kendine Konuşursa: Tarayıcıda Yaşanan Garip An yazımızda da bu konuya değinmiştik.
Ve işler burada ilginçleşiyor.
Asıl risk veri kaybından çok tekrar inşa etme yükü. Tekrardan kural yazmak kolay görünüyor ama aynı kaliteyi yakalamak hiç o kadar kolay değil.
Otomatik yedek neden daha mantıklı?
Vallahi, Lafı gevelemeden söyleyeyim: manuel backup romantik geliyor ama çoğu zaman işlemiyor. İnsan unutuyor. Erteleye biliyor. Hatta bazen canınız da istemiyor — zaten iş üstünde beş tane yangın var çünkü.
Bana göre claude-code-backup fikrinin iyi tarafı tam burada devreye giriyor; tool tüm kapsamları tarayıp yerelde temiz bir ağaca aktarıyor ve üstüne Git ile versiyonlayabiliyor. Bu ikinci kısım kritik. Çünkü snapshot almak başka, sürüm geçmişi tutmak başka şey.
- Tüm alanlarda keşif yapması faydalı. (bence en önemlisi)
- Sadece ana ~/.claude yoluna bakmaması önemli.
- Makineler arası taşımada işinizi hızlandırıyor. — ciddi fark yaratıyor
- Düzgün diff sayesinde neyin değiştiğini görebiliyorsunuz.
- Zamanlanmış görevle “unutma” sorununu azaltıyor.
Neyse, uzatmayayım. Linux tarafında systemd timer, macOS tarafında LaunchAgent yaklaşımı bence bayağı doğru seçim. En çok da Persistent=true mantığı güzel — makine kapalı kaldığında kaçırılan işi sonraki açılışta telafi etmesi hayat kurtarıyor. Ha, bu arada bunu test ederken kendi ThinkPad T14 üzerinde bilerek sistemi uykuya aldım; ertesi sabah kalkınca timer’ın devreye girmesi gayet temizdi.
Küçük ekiplerde etkisi daha büyük oluyor:
Eğer iki ya da beş kişilik minik bir ürün ekibindeyseniz, bütün bilgi tek tek omuzlarda taşınıyor demektir. O yüzden otomasyon burada lüks değil — sigorta gibi düşünün. Kurumsalda süreç vardır ama startup’ta süreç çoğu zaman insanların kafasının içindedir… ve kafanın içi de pek stabil değildir açıkçası.
Git geçmişi niçin kritik?
Açık konuşayım, bu kısım en sevdiğim bölüm oldu. Çünkü yedekleme dünyasında birçok araç size sadece son hali verir — ama iş günlük hayatta öyle yürümüyor. Bir rule’ü değiştirirsiniz, bir hafta sonra eski sürüm aslında daha iyiydi dersiniz. Ya da MCP bağlantısını optimize etmeye çalışırken küçük ama can sıkıcı bir regresyon çıkarırsınız (ben de ilk duyduğumda şaşırmıştım). Git burada resmen zaman makinesi rolünde (yanlış duymadınız)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
