[DOCS-1042] "Use Filesystem Snapshots to Backup and Restore" documentation is error-ridden and misguided Created: 25/Jan/13  Updated: 21/Feb/13  Resolved: 21/Feb/13

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Peter Burkholder Assignee: Sam Kleinman (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates DOCS-935 Snapshot Compression Method Clarifica... Closed
Participants:
Days since reply: 10 years, 51 weeks, 6 days ago

 Description   

Lots of issues here. My colleague has been working on this approach and it's made for a pretty lousy week for him. He might be able to provide more details, but to start:

  • Using tar with a raw device makes no sense
  • Docs should note that the lvm block-level dumps don't allow for incrementals
  • Wouldn't it make more sense to take a snapshot, mount it, and tar the files instead of doing the block-level dump/restore?


 Comments   
Comment by auto [ 21/Feb/13 ]

Author:

{u'date': u'2013-02-21T23:24:56Z', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}

Message: DOCS-1042 and DOCS-935 backup system clarifications and improvements
Branch: master
https://github.com/mongodb/docs/commit/d5c7080aefb0ce15cc3bc603004de2e724f4f6ef

Comment by Sam Kleinman (Inactive) [ 25/Jan/13 ]

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.
Generated at Thu Feb 08 07:40:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.