Manage File System Snapshot Storage¶
On this page
Ops Manager can back up MongoDB databases as snapshots to one or more of the following storage options:
- Another MongoDB database, called a Blockstore,
- As files stored on a local or network-attached file system, and/or
- An AWS S3 bucket.
This tutorial covers backing up your snapshots on file system storage.
You may have issues that require you to use more than one snapshot store like needing more capacity, localizing data, or meeting privacy regulations. To learn how to assign snapshot stores to different data centers, see Assign Snapshot Stores to Specific Data Centers.
Before creating any file system snapshot stores:
- Ensure storage volumes with sufficient capacity is attached to the Ops Manager server to store the snapshot files and the Oplog Store MongoDB database. The Oplog Store does not need to be on the same host as the file system snapshot store.
- Deploy the dedicated MongoDB instance(s) to host the Oplog Stores for this snapshot store.
- Ensure the host running the Ops Manager Backup Daemon service has sufficient capacity to store the head database.
- If you use multiple Ops Manager instances (including those activated as additional Backup Daemons), set up an NFS application or something similar to ensure the all instances share the same view of file system snapshot storage. If the Ops Manager instances do not share the same view of file system snapshot storage, restores are not possible and Ops Manager cannot remove expired snapshots.
If the Ops Manager instances do not share the same view of file system snapshot storage, Backup restores will not be possible and Ops Manager will not be able to remove expired snapshots.
Add a File System Store¶
Click Create New File System Store.¶
Complete the File System Store details.¶
|File System Store Name||A name for the file system store.|
|Path||The file system path in which the snapshot will be stored.|
|MMapV1 Compression Setting||Select whether or not MMapV1 storage engine snapshots are
compressed. Any backup job using MMapV1 snapshots inherits
this setting. The default value is
|WiredTiger Compression Setting||Select whether or not WiredTiger storage engine snapshots are
compressed. Any backup job using WiredTiger snapshots
inherits this setting. The default value is
|New Assignment Enabled checkbox||This enables the filestore once it has been created. If you leave this unchecked, the filestore is created but no newly started backups can be assigned to it.|
Edit an Existing File System Store¶
Once created, file system stores are listed directly on the Snapshot Storage page in a table. Each row contains the settings for each File System Store.
Navigate to the Snapshot Storage page.¶
- Click the Admin link.
- Click the Backup tab.
- Click the Snapshot Storage page.
Go to the row for the filestore you want to edit.¶
In the MongoDB Connection column, update any values that need to be changed in the following fields:¶
|Store Path||The location where file system-based backups are stored on the Ops Manager server.|
|Assignment Labels||A comma-separated list of labels to assign the filestores to specific groups.|
A proportional value of how backup jobs are assigned to the given snapshot store compared to other snapshot stores.
By default snapshot stores assign one shard per snapshot store.
If a snapshot store has more than one shard assigned, it would result in one snapshot store being backed up often than the another. This ratio of backup jobs to shards can be changed using the load factor.
An example of how the Load Factor affects backups:
You are backing up a 5 shard cluster. Your deployment has filestore (A) with one shard and blockstore (B) with four shards. These blockstores should not get equally distribution of backup jobs, as B is four times larger than A. B should get a Load Factor of 4 and A should get a Load Factor or 1.