MongoDB’de yedek hangi anı temsil ediyor?
MongoDB kullanan ekiplerin sık yanıldığı nokta şudur: Bir dump veya snapshot varsa geri döneriz sanılır. Oysa asıl soru, bu yedeğin hangi tutarlı anı temsil ettiğidir. Yazma trafiği devam ederken alınan eksik veya tutarsız kopya, restore edildiğinde sessiz veri sorunları üretebilir.
Replica set kullanıyorsanız oplog penceresi de önemlidir. Oplog, değişikliklerin sıralı kaydıdır ve belirli bir noktaya yaklaşmayı mümkün kılar. Ama pencere kısa tutulmuşsa, geç fark edilen olayda gerekli kayıtlar artık yoktur.
- Snapshot zamanı açık olmalıdır.
- Oplog penceresi RPO beklentisiyle uyumlu olmalıdır.
- Restore hedefi üretimden ayrı olmalıdır.
- Kritik koleksiyonlar uygulama sorgularıyla doğrulanmalıdır.
mongodump ne zaman yeterli olur?
Küçük veri setlerinde, düşük yazma trafiğinde veya planlı taşımalarda mongodump/mongorestore pratik olabilir. Ancak büyük veri, yoğun yazma veya belirli saniyeye dönüş ihtiyacı varsa dump tek başına yetersiz kalabilir.
Dump yaklaşımında süre de önemlidir. Yedek saatler sürüyorsa, başlangıç ve bitiş arasında veri değişmiş olabilir. Bu durumda uygulamayı kısa süreli durdurmak, secondary üzerinden almak veya daha uygun snapshot yaklaşımı düşünmek gerekir.
Küçük veri seti için dump/restore fikri
mongodump --uri="mongodb://source/app" --archive=app.archive --gzip mongorestore --uri="mongodb://restore-target/app" --archive=app.archive --gzip
Yoğun yazma alan sistemlerde tutarlılık ve zaman penceresi ayrıca değerlendirilmelidir.
Restore sonrası sadece koleksiyon saymayın
Koleksiyon sayısı ve doküman adedi yararlı sinyaldir ama yeterli değildir. Özellikle embed/reference karışık kullanılan modellerde, sipariş ile müşteri, ödeme ile sepet, kullanıcı ile yetki gibi ilişkiler uygulama seviyesinde doğrulanmalıdır.
MongoDB esnek şema sunduğu için restore sonrası tip farklılıkları da kontrol edilmelidir. Tarih alanı string’e dönmüş, sayı alanı metin olarak gelmiş veya kritik alan bazı dokümanlarda eksik kalmış olabilir.
Restore sonrası örnek kontroller
db.orders.countDocuments({ createdAt: { $gte: ISODate("2026-06-14T00:00:00Z") } })
db.orders.find({ customerId: { $exists: false } }).limit(5)
db.users.aggregate([
{ $project: { emailType: { $type: "$email" }, createdAtType: { $type: "$createdAt" } } },
{ $group: { _id: { emailType: "$emailType", createdAtType: "$createdAtType" }, count: { $sum: 1 } } }
])Tatbikat notu olmazsa restore bilgisi kalıcı olmaz
Her restore denemesinden sonra süre, veri boyutu, kullanılan yedek, karşılaşılan hata ve doğrulama sonucu yazılmalıdır. Bu kayıtlar, gerçek olay anında kimin ne yapacağını belirginleştirir.
MongoDB tarafında en iyi geri yükleme planı, uygulama ekibinin veri modelini bildiği ve operasyon ekibinin yedek zincirini kanıtlayabildiği plandır.