Buy Percona ServicesBuy Now!

mongodump vs "hot backup" file sizes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mongodump vs "hot backup" file sizes

    So previously we were using mongodump for backups w/ MongoDB 3.6.

    We just upgraded to Percona 4.0 and are now using "hot backup", ie db.runCommand({createBackup ...

    In both cases we've been .gz the backups.

    Any ideas why "hot backup" is nearly double the filesize? Is there any way to compress it even more? FYI the command we're using is "tar -zcvf", and with mongodumb it was "--gzip".

    Click image for larger version

Name:	Screenshot - 4_19_2019 , 11_00_27 PM.png
Views:	11
Size:	109.2 KB
ID:	53928

  • #2
    Anyone? Surely we can't be the only ones that have noticed this. It's a significant difference.

    Comment


    • #3
      Hi imk,
      >Any ideas why "hot backup" is nearly double the filesize? Is there any way to compress it even more? FYI the command we're using is "tar -zcvf", and with mongodumb it was "--gzip".


      I believe the compression method you do doesn't matter here. The key difference between the mongodump vs hotbackup is that :

      mongodump - logical backup
      hotbackup - binary backup
      So when you do backup with mongodump, you need to restore them and then have to use. So the index and key objects are created later when restoring. But with hotbackup, just do untar and start an instance with that directory, in other words - "ready to use backup" is possible with hotbackup. So with hotbackup, your downtime is reduced when failover on restore backup part and also requires nearly same size as your data directory. You can check this blog discussing about the same - https://www.percona.com/blog/2018/04...r-for-mongodb/


      Regards,
      Vinodh Krish

      Comment


      • #4
        Ok thanks for the explanation!

        You may want to update this part in the post "Binary-level backups can take a bit more space on disk" since it seems to take nearly double the space ... which could be a major concern for larger DBs.

        Comment

        Working...
        X