|
Thanks for pointing this out. We totally agree that the backup documentation needs some work, particularly the section that you point out. I look forward to hearing your colleague's feedback, and incorporating improvements as needed. For the moment:
- Agreed about tar I've meant to replace it with gzip for a couple of weeks, but haven't had the time to do the proper testing. In the mean time, while tar doesn't make sense, it's not harmful to use tar.
- That's fair. It's also the case that none of our documented backup methods will produce incremental backups as such. I can imagine building a backup system that provides something more incremental, either using rdiff-backup to export data from snapshots, or just storing snapshot/mongodump output in a deduplicating filesystem should do the trick.
- That's definitely a valid approach, and I think that we should include a note about this possibility. My reasoning for the current procedure is to minimize overhead on the host that's still running a production mongod as well as the overall time of the backup procedure. Compressing the entire filesystem may improve recovery times, and given the compression I wouldn't expect the size difference to be large (assuming that the dbpath was the entirety of the file system. If this doesn't match your experience, I'd be happy to add notes to this effect.
|