Uygulama Veritabanınızı Nasıl Yedeklersiniz (ve Gerçekten Geri Yükleyebilirsiniz)

Uygulama veritabanınızı yedeklemek için verileri bir zamanlamaya göre bir dosyaya aktarın (Postgres için standart araç pg_dump’dır), kopyaları veritabanından ayrı bir yerde saklayın ve bunlardan birini düzenli olarak boş bir veritabanına geri yükleyerek işe yaradığını kanıtlayın. Riskli bir değişiklikten hemen önce ek bir yedek alın. Kod yedeğiniz, yani bir GitHub deposu ya da bir dışa aktarma, verilerinizi içermez.

Bu rehber, bir uygulamayı küçük ölçekte işletip kaybetme endişesinden kurtulmak isteyenler içindir. Örneklerde Postgres kullanılır, çünkü yapay zekâyla oluşturulan uygulamaların çoğu bunu kullanır; ancak ilkeler herhangi bir veritabanı için geçerlidir.

Bir yedeğin neleri kapsaması gerekir

Bir uygulama yalnızca veritabanından ibaret değildir. Her yedeğin neyi koruduğunu bilin.

Veri, yeniden oluşturamayacağınız tek kısımdır. Kod yeniden yazılabilir, ayarlar yeniden girilebilir; müşterilerinizin siparişleri ise yeniden oluşturulamaz.

1. Adım: Ne kadar kayıp kabul edebileceğinize karar verin

Yedekleme planınızı iki soru belirler:

• Ne kadar güncel veriyi kaybetmeyi göze alabilirsiniz? Günde bir kez yedek alıyorsanız ve veritabanı akşam arızalanırsa, o günkü değişiklikleri kaybedersiniz. Bir hobi uygulaması için bu sorun olmayabilir. Sipariş alan bir uygulama için olabilir.
• Geri yükleme sırasında uygulama ne kadar süre kapalı kalabilir? Küçük bir veritabanı dakikalar içinde geri yüklenir. Büyük bir veritabanı çok daha uzun sürebilir ve buna ihtiyacınız olmadan önce bunu bilmek istersiniz.

Çoğu küçük uygulama için günlük otomatik yedek ve riskli değişikliklerden önce elle alınan bir yedek sağlam bir başlangıçtır. Para ya da sağlık verisi içeren uygulamalar daha sık yedek veya nokta-zamanı kurtarma (yalnızca son yedeğe değil, herhangi bir ana geri dönebilme) sunan yönetilen bir veritabanı gerektirir.

2. Adım: Barındırma sağlayıcınızın zaten ne yaptığını kontrol edin

Birçok yönetilen veritabanı sağlayıcısı otomatik yedek alır. Şunları öğrenin:

• Yedekler planınızda açık mı ve ne sıklıkla çalışıyor?
• Ne kadar süreyle saklanıyorlar?
• Belirli bir zamana mı geri dönebilirsiniz, yoksa yalnızca günlük bir anlık görüntüye mi?
• Yedeği indirebilir misiniz, yoksa yalnızca kendi sistemleri içinde mi geri yükleyebilirsiniz?

Sağlayıcı yedekleri faydalıdır, ancak veritabanınızla tek bir arıza noktasını paylaşırlar: hesap. Hesap kapatılır, askıya alınır veya proje silinirse yedekler de gidebilir. Bu yüzden kendi kopyanıza da ihtiyacınız vardır.

3. Adım: pg_dump ile döküm alın

pg_dump bir Postgres veritabanını bir dosyaya aktarır. Tutarlı bir anlık görüntü okur, dolayısıyla çalışırken uygulama çalışmaya devam edebilir.

Uygulamanızın zaten bir ortam değişkeninde sahip olduğu bağlantı dizesini kullanan tipik bir komut:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Seçeneklerin yaptığı işler:

• --format=custom, pg_restore’un okuyabildiği sıkıştırılmış bir dosya yazar ve daha sonra tek tek tabloları geri yüklemenize izin verir. Bunun yerine okunabilir bir .sql dosyası istiyorsanız --format=plain kullanın.
• --no-owner, sahiplik komutlarını dışarıda bırakır; bu da farklı bir veritabanına geri yüklemeyi kolaylaştırır.
• Dosya adındaki tarih, yedekleri birbirinden ayırır.

pg_dump sürümü, veritabanınızın Postgres sürümüyle aynı veya daha yeni olmalıdır. Eski bir pg_dump çalışmayı reddedebilir.

Yapay zekâyla geliştiriyorsanız ve komut satırına dokunmak istemiyorsanız şunu isteyebilirsiniz:

Uygulamanın veritabanının pg_dump ile özel biçimde bir yedeğini al; dosya adında bugünün tarihi olsun. Bağlantı dizesini ya da başka bir gizli bilgiyi yazdırma. Bittiğinde dosya adını ve boyutunu bildir.

4. Adım: Otomatikleştirin

Elle alınan yedekler unutulur. Desteklediğiniz araçla otomatikleştirin:

• Veritabanı sağlayıcınızın zamanlanmış yedekleri, eğer sunuyorsa.
• Bir sunucuda veya CI servisinde zamanlanmış bir iş; bu iş pg_dump çalıştırır ve dosyayı depolamaya yükler.
• Veritabanınıza bağlanan barındırılan bir yedekleme servisi.

Hangisini seçerseniz seçin, bir yedek başarısız olduğunda size haber vermesini sağlayın. Üç aydır sessizce başarısız olan bir yedekleme işi klasik korku hikâyesidir.

5. Adım: Kopyaları başka bir yerde saklayın

Genellikle 3-2-1 kuralı olarak anılan ilke şudur: verinizin üç kopyası, iki farklı depolama türünde ve bir kopyası site dışında. Küçük bir uygulama için pratik uygulama şöyledir:

• Canlı veritabanı
• Sağlayıcının kendi otomatik yedekleri
• Farklı bir hesaptaki bir nesne depolama kovası gibi ayrı bir depolamada kendi dökümleriniz

Ayrıca:

• Erişimi kısıtlayın. Bir yedek her kullanıcının verisini içerir. Onu canlı veritabanı gibi koruyun.
• Bir saklama politikası belirleyin. Örneğin günlük yedekleri iki hafta, aylık olanları bir yıl tutun. Eski yedekleri bilinçli olarak silin ve gizlilik yasalarının kişisel verileri talep üzerine silmenizi gerektirebileceğini unutmayın.
• Yedekleri asla Git’e eklemeyin. Bir depodaki döküm, bekleyen bir veri sızıntısıdır.

6. Adım: Bir geri yüklemeyi test edin

Bir yedek, yalnızca son başarılı geri yüklemeniz kadar iyidir. En azından birkaç ayda bir ve yedekleme sürecinde her değişiklikten sonra:

1. Yeni, boş bir veritabanı oluşturun. Test için asla canlı veritabanının üzerine geri yüklemeyin.
2. En son yedeği buraya geri yükleyin:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Düz bir .sql dosyası için bunun yerine psql "$TEST_DATABASE_URL" -f backup.sql kullanın.

1. Her tablonun var olduğunu doğrulayın, satır sayılarını canlı veritabanıyla karşılaştırın ve birkaç yeni kayda bakın.
2. Mümkünse uygulamanın bir kopyasını buna bağlayın ve giriş yapın.
3. Geri yüklemenin ne kadar sürdüğünü not edin. Gerçek kurtarma süreniz budur.

7. Adım: Riskli değişikliklerden önce yedek alın

Hemen önce yeni bir yedek alın:

• Sütun silen veya yeniden adlandıran bir veritabanı geçişi çalıştırırken
• Toplu veri içe aktarırken
• Bir yapay zekâ ajanının veri modelinde büyük değişiklikler yapmasına izin verirken
• Eski kayıtları silerken

Yapay zekâyla oluşturulan bir uygulamada ajan, bir özelliğin parçası olarak tablo yapısını değiştirebilir. Kontrol noktaları ve sürüm kontrolü kodunuzu geri alır, ama silinmiş satırları geri getirmez. Büyük bir değişiklikten önceki otuz saniyelik bir yedek, ucuz bir sigortadır.

Sık yapılan hatalar

• Git’in veya bir kod dışa aktarmanın yedek olduğunu varsaymak. Kodu içerir, verileri değil.
• Bir geri yüklemeyi hiç test etmemek. Birçok yedek, ihtiyaç duyulduğunda ancak boş, eksik veya okunamaz çıkar.
• Yedekleri veritabanıyla aynı hesapta tutmak. Tek bir ele geçirilmiş veya kapatılmış hesap ikisini de kaybettirir.
• Yüklenen dosyaları unutmak. Veritabanı dosyanın yolunu saklar; resmin kendisi depolamada durur.
• Yedekleme betiklerinde gizli bilgi bırakmak. Bağlantı dizesini betiğin metninden değil, bir ortam değişkeninden okuyun. Bkz. API anahtarlarınızı nasıl güvende tutarsınız.

Yedekler ve Mythex

Mythex projeleri kendi özel Postgres veritabanına sahip olabilir ve bağlantı bilgileri çalışma alanına ve yayınlanmış uygulamaya enjekte edilir. Mythex dokümanları bir veritabanı yedekleme veya geri yükleme özelliğini anlatmaz, bu yüzden kendi planınızı yapın: ajandan bir döküm oluşturmasını isteyin, indirin ve güvenli bir yerde saklayın; özellikle büyük değişikliklerden önce. Bir proje dışa aktarımı (Pro) kodunuzu içerir; gizli bilgiler ve node_modules dışarıda bırakılır, veritabanı satırlarını içermez. Ayrıntılar için dokümanlardaki Veritabanı ve Veri sahipliği bölümlerine bakın. Veritabanının kendisi hakkında daha fazlası için Postgres nedir rehberini okuyun.

Yedekleme kontrol listesi

• Ne kadar veri kaybını kabul edebileceğinize ve ne kadar süre kapalı kalabileceğinize karar verdiniz
• Veritabanı sağlayıcınızın sunduğu otomatik yedekleri kontrol ettiniz
• Kendi dökümünüz zamanlanmış çalışıyor ve hataları size bildiriyor
• Kopyalar veritabanından ayrı, erişimi kısıtlı bir yerde saklanıyor
• Saklama politikası yazılı
• Yüklenen dosyalar da veritabanı kadar yedekleniyor
• Geri yükleme boş bir veritabanına test edildi ve satır sayıları kontrol edildi
• Her riskli değişiklikten önce yedek alınıyor

Sorular