Configure Block Size in a Blockstore

Full Snapshot after Change to Block Size

If you change the block size, the next snapshot runs as a full snapshot rather than an incremental snapshot.

Increased Block Size Increases Performance and Disk Usage

In general, increasing block size results in faster snapshots and restores, but requires more disk space. Consider these competing factors when determining if you should tune the block size.

In these two exceptions performance improves as the block size increases without requiring additional disk space:

Check Disk Capacity Before Changing Block Size

Before changing the block size, check that your MongoDB blockstore can fit in the current disk space after the change. Snapshots after the change can't deduplicate blocks of earlier snapshots. The block sizes won't match. This results in each blockstore’s disk usage increasing by the size of the deployments they back up.

Blockstores that can't store new blocks crash. This blocks backups. Clear space from disk to return the blockstore to working order.

To check if you have enough disk space to change the block size for a given job, complete the following procedure:

1. Discover the amount of available disk space on the host running the blockstore.

2. Estimate the amount by which the blockstore storage usage increases when it adds the compressed bytes of the next snapshot. Review the compressed bytes of the backup job’s most recent snapshot to make that estimate.

   To review the compressed bytes, run the following query:

   1
   db.getSiblingDB("backupjobs").snapshots.findOne(
   2
     {
   3
       rsId : <rsId>,
   4
       groupId : <groupId>,
   5
       completed: true
   6
     }, {
   7
       compressedSize: 1
   8
     }, {
   9
       sort: {
   10
         startTime: -1
   11
       }
   12
     }
   13
   )

3. Scale up the value you found to leave some buffer room.

   1. The blockstore storage usage spikes with the first snapshot taken after increasing block size. Subsequent snapshots with that new block size also grow the blockstore. Not all of their blocks deduplicate with that first snapshot.

   2. If Ops Manager reclaims space using one blockstore (an intra-blockstore groom job), the blockstore needs a greater amount of buffer space. During an intra-blockstore groom job, the blockstore allocates space temporarily for the following:

      • the dead bytes from previously expired snapshots

      • two copies of the living bytes of all previously completed snapshots

      • two copies of the bytes from the new snapshot

4. Compare the disk space found in step 1 and step 3. The disk space calculated in step 3 should fit in the disk space found in step 1.

If your host lacks sufficient disk space to change the block size for a given job, try one of the following solutions:

• Add more disk space for the blockstores.

• Terminate and restart backup jobs. This purges all existing snapshots.

• Run one or more groom jobs from the Grooms Priority admin page to clear some dead bytes. To see how much data you can actually clean for each job, check the Resource Usage admin page.

• Add a new blockstore then schedule inter-blockstore groom job for some of the backup jobs.

• Leave block size unchanged.

  Ops Manager displays the banner to increase block size if you never configured block size for one or more backups with FCV 4.2 or later and a MongoDB blockstore. To dismiss the banner, set any block size for all backup jobs. You can set the old default block size of 64 KB.

If you need help, contact MongoDB Support