Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-1296

Comment on: "manual/tutorial/backup-databases-with-filesystem-snapshots.txt": filenames and remote/local compression/decompression.

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Done
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None

    Description

      Hi,

      some comments on 'http://docs.mongodb.org/manual/tutorial/backup-databases-with-filesystem-snapshots/':

      • section 'Backup and Restore Using LVM on a Linux System', subsection 'Archive a Snapshot', I am reading 'dd if=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.tar.gz': why .tar ? This is not a tar file, should we not read 'dd if=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.gz' instead ?
      • section 'Backup and Restore Using LVM on a Linux System', subsection 'Restore a Snapshot': same as above for 'gzip -d -c mdb-snap01.tar.gz | dd of=/dev/vg0/mdb-new', and if not fixed for some reason, you might want to update 'Uncompresses and unarchives the mdb-snap01.gz into the mdb-new disk image.' which correctly refer to a file without '.tar'.
      • section 'Backup and Restore Using LVM on a Linux System', subsection 'Remote Backup Storage': same as above.
      • section 'Backup and Restore Using LVM on a Linux System', subsection 'Remote Backup Storage': the procedures described in this section use lot of bandwidth, is it done on purpose (remove CPU usage on the server serving the database) ? A note might be welcome to explain the trade-off between doing local and remote compression/decompression.

      Feel free to contact me fore more information.

      Best regards,

      Jean-François Gagné
      jean.francois.gagne.1977@gmail.com

      Attachments

        Activity

          People

            sam.kleinman Sam Kleinman (Inactive)
            auto auto
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:
              10 years, 47 weeks, 2 days ago