MongoDB Yedekleme: mongodump ve Restore

MongoDB yedekleme konusunda gördüğüm en yaygın yanılgı, replica set kurmuş olmayı yedeklenmiş olmakla karıştırmaktır. Replikasyon sunucu arızasına karşı korur; yanlışlıkla çalıştırılan bir deleteMany komutuna karşı korumaz, çünkü o silme işlemi saniyeler içinde tüm üyelere yayılır ve hiçbir kopyada eski veri kalmaz. Uygulama hatasına, insan hatasına ve fidye yazılımına karşı tek savunmanız, sunucudan bağımsız bir yerde duran ve geri yüklenebilirliği test edilmiş bir yedektir.

Bu rehberde MongoDB'nin resmî mantıksal yedekleme aracı olan mongodump ile nasıl doğru yedek alacağınızı, mongorestore ile nasıl geri döneceğinizi ve bu ikisini otomatik bir betiğe nasıl bağlayacağınızı anlatacağım. Arşiv ve sıkıştırma seçeneklerini, replica set üzerinde zaman tutarlı yedek almanın yolu olan --oplog bayrağını, geri yüklemeyi doğrulama yöntemlerini ve saklama politikasını tek tek göreceğiz. Sonunda mongodump'ın nerede yetersiz kaldığını ve ne zaman dosya sistemi anlık görüntüsüne geçmeniz gerektiğini de konuşacağız.

mongodump Ne Yapar, Ne Yapmaz#

mongodump, veritabanındaki belgeleri okuyup BSON biçiminde dosyalara yazan mantıksal bir yedekleme aracıdır. Yani veri dosyalarının bayt kopyasını almaz; her koleksiyonu sorgulayıp içeriğini dışa aktarır. Bunun iki önemli sonucu vardır.

Birincisi, çıktı taşınabilirdir: farklı MongoDB sürümlerine, farklı işletim sistemlerine, hatta farklı depolama motoruna sahip bir sunucuya geri yükleyebilirsiniz. İkincisi, index'lerin verisi yedeğe dahil edilmez; yalnızca tanımları metadata.json dosyalarına yazılır ve geri yükleme sırasında sıfırdan yeniden oluşturulur. Bu yüzden büyük koleksiyonlarda geri yükleme, yedek almaktan çok daha uzun sürer — süreyi belirleyen şey belgelerin yazılması değil, index'lerin yeniden inşasıdır.

mongodump şunları yapmaz ve bunu bilmek beklentinizi doğru kurar: çalışan sunucuyu durdurmaz ama yükünü artırır; varsayılan hâliyle koleksiyonlar arası tutarlı bir an yakalamaz (bunun için --oplog gerekir); kullanıcı ve rol tanımlarını yalnızca admin veritabanını da dahil ederseniz alır; ve terabaytlık veri kümeleri için pratik bir araç değildir.

Kurulum, Parola Güvenliği ve İlk Yedek#

MongoDB 4.4 ile birlikte mongodump ve mongorestore sunucu paketinden ayrıldı; ayrı bir paket olarak kurulur:

# Debian / Ubuntu
sudo apt update
sudo apt install -y mongodb-database-tools

# Sürümü doğrula
mongodump --version

Parolayı komut satırına yazmak, sunucudaki her kullanıcının ps aux çıktısında görebileceği anlamına gelir. İki temiz alternatif var. Birincisi parolayı hiç vermemek: --username yazıp --password yazmazsanız araç sizden interaktif olarak ister. İkincisi, otomatik betikler için uygun olanı, izinleri kısıtlanmış bir yapılandırma dosyası kullanmaktır:

# /etc/mongodb/yedek.conf — yalnızca root okuyabilir
sudo install -o root -g root -m 600 /dev/null /etc/mongodb/yedek.conf
sudo tee /etc/mongodb/yedek.conf > /dev/null << 'YAPILANDIRMA'
password: CokGucluBirParola
YAPILANDIRMA

Şimdi ilk yedeği alalım. Dizin tabanlı klasik biçim, her koleksiyon için ayrı bir .bson dosyası üretir:

mongodump \
  --host="mongo1.firmaniz.com:27017" \
  --username="yedekci" \
  --authenticationDatabase="admin" \
  --config=/etc/mongodb/yedek.conf \
  --db="uygulamadb" \
  --out="/var/backups/mongo/2026-08-25" \
  --gzip

# Sonuç yapısı
# /var/backups/mongo/2026-08-25/uygulamadb/siparisler.bson.gz
# /var/backups/mongo/2026-08-25/uygulamadb/siparisler.metadata.json.gz

Yedekleme kullanıcısının root yetkisine ihtiyacı yoktur; backup rolü tam olarak bu iş için vardır ve yedekçi hesabın ele geçirilmesi durumunda hasarı sınırlar:

use admin
db.createUser({
  user: "yedekci",
  pwd: passwordPrompt(),
  roles: [ { role: "backup", db: "admin" } ]
})

Arşiv, Sıkıştırma ve Seçici Yedekleme#

Dizin yapısı okunaklıdır ama binlerce küçük dosya, uzak depoya kopyalarken zahmetlidir. --archive seçeneği tüm yedeği tek bir dosyaya, hatta doğrudan bir boruya (pipe) yazar:

# Tek dosya, sıkıştırılmış
mongodump --uri="mongodb://[email protected]:27017/?authSource=admin" \
  --config=/etc/mongodb/yedek.conf \
  --db=uygulamadb \
  --archive=/var/backups/mongo/uygulamadb-2026-08-25.archive.gz \
  --gzip

# Ara dosya olmadan doğrudan başka bir sunucuya aktarma
mongodump --uri="mongodb://localhost:27017" --db=uygulamadb --archive --gzip \
  | ssh [email protected] 'cat > /depo/uygulamadb-2026-08-25.archive.gz'

Seçici yedekleme, geçici ve yeniden üretilebilir koleksiyonları dışarıda bırakarak hem süreyi hem de depolama maliyetini düşürür:

mongodump --uri="mongodb://localhost:27017" --db=uygulamadb \
  --excludeCollection=oturumlar \
  --excludeCollection=gecici_kuyruk \
  --excludeCollectionsWithPrefix=cache_ \
  --archive=/var/backups/mongo/uygulamadb-ince.archive.gz --gzip

Yedeği birincil sunucudan değil, bir ikincil üyeden almak da iyi bir alışkanlıktır; böylece yedekleme yükü uygulamanın hizmet verdiği düğüme binmez:

# Replica set'e bağlan, okumayı ikincilden yap
mongodump --uri="mongodb://mongo1.firmaniz.com:27017,mongo2.firmaniz.com:27017,mongo3.firmaniz.com:27017/?replicaSet=rs0&authSource=admin" \
  --username=yedekci --config=/etc/mongodb/yedek.conf \
  --readPreference=secondary \
  --db=uygulamadb --archive=/var/backups/mongo/gece.archive.gz --gzip

Replica set topolojisini henüz kurmadıysanız MongoDB replica set kurulumu yazısı bu yapıyı adım adım anlatıyor; yedekleme stratejisinin ikinci ayağı odur.

Replica Set'te Zaman Tutarlı Yedek Almak#

Varsayılan mongodump, koleksiyonları sırayla okur. İlk koleksiyonu okurken geçen sürede son koleksiyona yeni kayıtlar eklenmiş olabilir; sonuçta elinizdeki yedek, hiçbir zaman gerçekten var olmamış bir ara duruma karşılık gelir. Tek bir koleksiyonda sorun değildir ama sipariş ve ödeme gibi birbirine bağlı koleksiyonlarda bu tutarsızlık gerçek bir problemdir.

Çözüm --oplog bayrağıdır. Yedek sürerken oplog'a düşen değişiklikleri de kaydeder, geri yüklemede --oplogReplay ile bu değişiklikler uygulanır ve elinizde yedeğin bittiği ana karşılık gelen tutarlı bir kopya olur:

# Yalnızca replica set üyesinde çalışır, tek düğümde hata verir
mongodump --uri="mongodb://mongo2.firmaniz.com:27017/?replicaSet=rs0&authSource=admin" \
  --username=yedekci --config=/etc/mongodb/yedek.conf \
  --oplog \
  --archive=/var/backups/mongo/tutarli-2026-08-25.archive.gz --gzip

--oplog kullanırken üç kural var. Birincisi, tek bir veritabanını değil tüm örneği yedeklemeniz gerekir; --db ile birlikte kullanılamaz. İkincisi, yedekleme süresi oplog penceresinden kısa olmalıdır — yedek üç saat sürüyor ama oplog'unuz yalnızca bir saatlik geçmiş tutuyorsa, tekrar oynatılacak kayıtlar çoktan silinmiş olur ve işlem başarısızlıkla biter. Pencerenizi kontrol edin:

rs.printReplicationInfo()
// log length start to end: 92736secs (25.76hrs)

Üçüncüsü, geri yüklerken --oplogReplay bayrağını vermeyi unutmayın; unutursanız yedek yine yüklenir ama tutarlılık garantisi kaybolur.

mongorestore ile Geri Yükleme ve Doğrulama#

Geri yükleme, yedeğin ayna işlemidir ama birkaç bayrak hayat kurtarır. En önemlisi --drop: hedefteki koleksiyonları yüklemeden önce siler, böylece eski ve yeni kayıtların karışması engellenir.

# Arşiv dosyasından tam geri yükleme
mongorestore --uri="mongodb://mongo1.firmaniz.com:27017/?replicaSet=rs0&authSource=admin" \
  --username=yonetici --config=/etc/mongodb/yedek.conf \
  --archive=/var/backups/mongo/uygulamadb-2026-08-25.archive.gz \
  --gzip --drop

# Dizin biçimindeki yedekten yalnızca bir koleksiyon
mongorestore --uri="mongodb://localhost:27017" \
  --nsInclude="uygulamadb.siparisler" \
  --gzip --drop \
  /var/backups/mongo/2026-08-25

Bir yedeği canlı veritabanının üzerine değil, önce ayrı bir isim alanına yüklemek en güvenli yaklaşımdır. --nsFrom ve --nsTo bunu tek satırda yapar:

# uygulamadb yedeğini test veritabanına yükle, üretime dokunma
mongorestore --uri="mongodb://localhost:27017" \
  --archive=/var/backups/mongo/uygulamadb-2026-08-25.archive.gz --gzip \
  --nsFrom='uygulamadb.*' --nsTo='uygulamadb_test.*'

Geri yükleme bittikten sonra mutlaka doğrulayın. Yedeğin "başarıyla tamamlandı" demesi, verinin doğru olduğu anlamına gelmez:

// Belge sayılarını karşılaştır
db.getSiblingDB("uygulamadb_test").siparisler.countDocuments()
db.getSiblingDB("uygulamadb_test").musteriler.countDocuments()

// Index'lerin yeniden oluştuğunu doğrula
db.getSiblingDB("uygulamadb_test").siparisler.getIndexes().length

// En yeni kaydın tarihine bak — yedeğin gerçekten güncel olduğunu gösterir
db.getSiblingDB("uygulamadb_test").siparisler.find().sort({ olusturma: -1 }).limit(1)

Büyük yedeklerde geri yükleme süresini kısaltmak için paralellik seçeneklerini kullanabilirsiniz; ancak bunlar sunucuya ek yük bindirir, üretim ortamında ölçerek artırın:

mongorestore --numParallelCollections=4 --numInsertionWorkersPerCollection=4 \
  --archive=/var/backups/mongo/uygulamadb.archive.gz --gzip

Otomatik Yedekleme Betiği ve Saklama Politikası#

Elle alınan yedek, alınmayan yedektir. Aşağıdaki betik günlük yedek alır, eskileri siler ve sonucu günlüğe yazar. Kritik nokta, yedeğin aynı sunucuda kalmaması: disk arızasında hem veriyi hem yedeği kaybedersiniz.

#!/usr/bin/env bash
# /usr/local/bin/mongo-yedek.sh
set -euo pipefail

HEDEF="/var/backups/mongo"
TARIH="$(date +%F)"
DOSYA="${HEDEF}/uygulamadb-${TARIH}.archive.gz"
SAKLAMA_GUN=14
UZAK="[email protected]:/depo/mongo/"

mkdir -p "$HEDEF"

# Yedeği al (ikincil üyeden okuyarak birincili yormadan)
mongodump \
  --uri="mongodb://mongo1.firmaniz.com:27017,mongo2.firmaniz.com:27017/?replicaSet=rs0&authSource=admin" \
  --username=yedekci --config=/etc/mongodb/yedek.conf \
  --readPreference=secondary \
  --db=uygulamadb --archive="$DOSYA" --gzip --quiet

# Dosya gerçekten oluştu ve boş değil mi
if [ ! -s "$DOSYA" ]; then
  logger -t mongo-yedek "HATA: yedek dosyasi bos veya olusmadi: $DOSYA"
  exit 1
fi

# Uzak depoya kopyala
rsync -a --partial "$DOSYA" "$UZAK"

# Yerelde eski yedekleri temizle
find "$HEDEF" -name 'uygulamadb-*.archive.gz' -mtime "+${SAKLAMA_GUN}" -delete

logger -t mongo-yedek "Tamam: $(du -h "$DOSYA" | cut -f1) -> $UZAK"

Betiği kurup zamanlayın:

sudo install -m 750 -o root -g root mongo-yedek.sh /usr/local/bin/mongo-yedek.sh
sudo crontab -e

# Her gece 03:15'te yedek al
15 3 * * * /usr/local/bin/mongo-yedek.sh >> /var/log/mongo-yedek.log 2>&1

Saklama politikası için pratik bir düzen şudur: son 14 günlük günlük yedek, son 8 haftanın haftalık yedeği, son 12 ayın aylık yedeği. Bu düzen, "üç hafta önce bozulmuş bir kaydı geri getirin" talebine cevap verebilmenizi sağlar. Sunucudan bağımsız bir kopya için yedekleme hizmetimiz ya da nesne depolama gibi harici bir hedef kullanın; aynı makinede duran yedek, yedek sayılmaz.

Kullanıcıları, Rolleri ve Sunucu Yapılandırmasını Yedeklemek#

Felaket senaryosunu zihninizde canlandırın: sunucu tamamen gitti, yeni bir makine kurdunuz, mongorestore ile veriyi geri yüklediniz ve uygulamanız hâlâ bağlanamıyor. Sebep neredeyse her zaman aynıdır — kullanıcılar ve roller geri gelmemiştir. Çünkü bunlar uygulama veritabanında değil, admin veritabanının system.users ve system.roles koleksiyonlarında durur. Yalnızca --db=uygulamadb yedekliyorsanız kimlik bilgileriniz yedeğin dışında kalmıştır.

Bunun iki çözümü var. Basit olanı, veritabanı adı vermeden tüm örneği yedeklemektir; --db bayrağını hiç kullanmazsanız mongodump bütün veritabanlarını, admin dahil, dışa aktarır. Yalnızca uygulama verisini yedeklemek istiyorsanız ikinci bir yedek işiyle kimlik tanımlarını ayrıca almanız gerekir:

# Kullanıcı ve rol tanımlarını ayrıca yedekle
mongodump --uri="mongodb://localhost:27017/?authSource=admin" \
  --username=yedekci --config=/etc/mongodb/yedek.conf \
  --db=admin --collection=system.users \
  --archive=/var/backups/mongo/kullanicilar-2026-08-25.archive.gz --gzip

# Geri yüklerken kullanıcıları da içeren yedekte bu bayrak gerekir
mongorestore --uri="mongodb://localhost:27017/?authSource=admin" \
  --username=yonetici --config=/etc/mongodb/yedek.conf \
  --restoreDbUsersAndRoles --db=uygulamadb \
  --archive=/var/backups/mongo/uygulamadb-2026-08-25.archive.gz --gzip

Aynı mantık sunucu yapılandırması için de geçerlidir. Bir felaket sonrası hızlı toparlanmanın en büyük düşmanı, "bu sunucuda hangi ayarlar vardı" sorusudur. /etc/mongod.conf dosyasını, replica set yapılandırmasını ve varsa anahtar dosyasını da yedekleme kapsamınıza alın; bunlar birkaç kilobayt yer kaplar ama geri dönüş süresini saatlerden dakikalara indirir.

# Yapılandırma anlık görüntüsü — veri yedeğinin yanına konur
sudo tar czf /var/backups/mongo/yapilandirma-$(date +%F).tar.gz \
  /etc/mongod.conf /etc/mongodb/

# Replica set yapılandırmasını okunabilir biçimde sakla
mongosh --quiet --eval 'JSON.stringify(rs.conf(), null, 2)' \
  > /var/backups/mongo/rs-conf-$(date +%F).json

Bir de kurtarma senaryonuzu yazılı hâle getirin. "Hangi dosyayı, hangi sunucuya, hangi komutla yükleyeceğim" sorusunun cevabı, felaket anında hatırlamaya çalışılacak bir şey olmamalı. Beş satırlık bir kurtarma notu, gece üçte bakılacak en değerli belgedir.

Sınırlar, Alternatifler ve Sık Yapılan Hatalar#

mongodump her ölçekte doğru araç değildir. Veri kümeniz birkaç yüz gigabaytı aştığında yedek süresi ve özellikle geri yükleme süresi kabul edilemez hâle gelir; index'lerin yeniden inşası saatler sürebilir. Bu noktada dosya sistemi anlık görüntüsü (LVM, ZFS ya da bulut sağlayıcısının disk anlık görüntüsü) çok daha uygundur: index'ler dahil her şeyin bayt kopyasını alır ve geri dönüş neredeyse anlıktır. Karşılığında taşınabilirliği kaybedersiniz — aynı MongoDB sürümü ve aynı platform gerekir.

Sık yapılan hataları sıralayayım:

1. Geri yükleme testi yapmamak. Bir yedeğin geçerliliği, ancak geri yüklendiğinde kanıtlanır. Ayda bir kez yedeği ayrı bir sunucuya ya da --nsTo ile ayrı bir isim alanına yükleyip belge sayılarını karşılaştırın.
2. Yedeği aynı diskte tutmak. Disk arızası ya da fidye yazılımı ikisini birden alır. En az bir kopya farklı bir makinede, mümkünse farklı bir konumda olmalıdır.
3. admin veritabanını atlamak. Yalnızca --db=uygulamadb yedekliyorsanız kullanıcı ve rol tanımlarınız yedekte yoktur; felaket anında veriyi geri yükleyip kimsenin bağlanamadığını fark edersiniz.
4. Parolayı komut satırına yazmak. ps aux çıktısında herkes görür ve kabuk geçmişine düşer. Yapılandırma dosyası ya da interaktif istem kullanın.
5. --oplog ile --db bayraklarını birlikte kullanmaya çalışmak. İkisi bağdaşmaz; tutarlı yedek tüm örneği kapsamak zorundadır.
6. Yedeğin bittiğini kontrol etmemek. Betiğinize mutlaka dosya boyutu ve çıkış kodu denetimi koyun; sessizce başarısız olan bir cron görevi, aylar sonra fark edilir.

İlişkisel veritabanı tarafında aynı disiplinin nasıl kurulduğunu görmek isterseniz mysqldump ile veritabanı yedekleme yazısındaki betik ve saklama mantığı doğrudan uyarlanabilir.

Sıkça Sorulan Sorular#

mongodump çalışırken veritabanı kilitlenir mi#

Hayır, mongodump veritabanını kilitlemez; koleksiyonları normal sorgularla okur ve bu sırada yazma işlemleri devam eder. Ancak okuma yükü ciddi olabilir, özellikle veri kümesi bellekten büyükse disk erişimi artar ve uygulama sorguları yavaşlayabilir. Bu yüzden yedeği yoğun olmayan saatlerde ve mümkünse bir ikincil üyeden almak en iyisidir.

mongodump yedeği index'leri de içerir mi#

Index tanımları yedeğe dahil edilir ama index'lerin kendisi, yani oluşturulmuş veri yapıları dahil edilmez. Her koleksiyonun yanındaki metadata.json dosyasında index tanımları durur ve mongorestore bunları geri yükleme sonunda sıfırdan oluşturur. Bu yüzden geri yükleme, yedek almaktan belirgin biçimde uzun sürer; süreyi belirleyen esas iş index inşasıdır.

Yedek almak ne kadar sürer#

Süreyi belirleyen üç şey var: veri hacmi, disk hızı ve sıkıştırma kullanıp kullanmadığınız. Kabaca bir fikir vermek gerekirse, hızlı bir NVMe diskte ve sıkıştırma açıkken onlarca gigabaytlık bir veritabanı dakikalar mertebesinde yedeklenir. Kesin süreyi öğrenmenin tek yolu kendi ortamınızda bir kez ölçmektir; ölçtüğünüz süreyi oplog pencerenizle karşılaştırmayı da unutmayın.

Yedeği başka bir sunucuya nasıl taşırım#

En pratik yol --archive seçeneğiyle tek dosya üretip rsync ya da scp ile kopyalamaktır. Ara dosya oluşturmak istemiyorsanız mongodump --archive --gzip çıktısını doğrudan bir SSH borusuna verebilirsiniz; bu, disk alanı kısıtlı sunucularda çok işe yarar. Hedefte mongorestore --archive=dosya --gzip komutuyla geri yüklersiniz.

Silinen bir koleksiyonu yedekten nasıl geri getiririm#

Tüm veritabanını geri yüklemeye gerek yok. mongorestore --nsInclude="uygulamadb.silinen_koleksiyon" parametresiyle yalnızca o koleksiyonu seçebilirsiniz. Üretim verisine dokunmamak için önce --nsTo ile geçici bir isim alanına yükleyip içeriği doğrulamanızı, ardından doğru koleksiyona taşımanızı öneririm. Böylece yanlış bir yedekle üretimin üzerine yazma riskini ortadan kaldırırsınız.

mongodump yerine ne kullanmalıyım#

Veri kümeniz birkaç yüz gigabaytı aştıysa ya da geri yükleme süresi iş sürekliliğiniz için çok uzunsa dosya sistemi anlık görüntüsüne geçin; LVM, ZFS ya da bulut disk anlık görüntüleri index'ler dahil her şeyi bayt düzeyinde kopyalar ve geri dönüş çok daha hızlıdır. Karşılığında aynı MongoDB sürümü ve platformu gerekir. Sürekli koruma ve zamana dönüş istiyorsanız yönetilen bir yedekleme çözümü daha uygun olur.

Kapanış#

MongoDB yedeklemesinde işin özü birkaç alışkanlıkta toplanıyor: yedeği ikincil üyeden ve sıkıştırılmış arşiv olarak alın, replica set üzerinde tutarlılık gerekiyorsa --oplog kullanın, admin veritabanını da kapsayın ve en önemlisi her yedeği aynı sunucudan uzağa kopyalayın. Bunların üstüne bir de düzenli geri yükleme testi koyun; test edilmemiş bir yedek, olmayan bir yedektir ve bunu ancak felaket anında öğrenirsiniz.

Yedeklerinizi sunucudan bağımsız bir yerde tutmak istiyorsanız yedekleme hizmetimiz bu işi düzenli ve denetlenebilir hâle getirir. Veritabanınızı tam kaynak garantisiyle kendi makinenizde çalıştırmak için VDS ve bulut sunucu paketlerimize, kurulum ile bakım yükünü devretmek içinse sunucu yönetimi hizmetimize göz atabilirsiniz.