From 497d06cfe92481f6bbac88c6c86c6980b90f3661 Mon Sep 17 00:00:00 2001 From: Anastasia Alexadrova Date: Mon, 11 Mar 2024 16:03:05 +0100 Subject: [PATCH] PBM-1255 Added icons for external links and icons for tabs --- docs/details/storage-configuration.md | 22 +-- docs/details/versions.md | 6 +- docs/features/comparison.md | 2 +- docs/features/incremental-backup.md | 6 +- docs/features/physical.md | 14 +- docs/features/point-in-time-recovery.md | 18 +- docs/features/snapshots.md | 8 +- docs/index.md | 2 +- docs/install/configure-authentication.md | 16 +- docs/install/docker.md | 8 +- docs/install/repos.md | 14 +- docs/install/source.md | 6 +- docs/install/tarball.md | 4 +- docs/installation.md | 2 +- docs/manage/automate-s3-access.md | 12 +- docs/manage/upgrading.md | 224 ++++++++++++----------- docs/pmm.md | 6 +- docs/troubleshoot/status.md | 88 ++++----- docs/troubleshoot/troubleshooting.md | 72 ++++---- docs/usage/delete-backup.md | 70 +++---- docs/usage/describe-backup.md | 4 +- docs/usage/list-backup.md | 24 +-- docs/usage/pitr-tutorial.md | 4 +- docs/usage/restore.md | 28 +-- docs/usage/schedule-backup.md | 6 +- docs/usage/start-backup.md | 30 +-- 26 files changed, 353 insertions(+), 343 deletions(-) diff --git a/docs/details/storage-configuration.md b/docs/details/storage-configuration.md index 1c2ff530..823ded85 100644 --- a/docs/details/storage-configuration.md +++ b/docs/details/storage-configuration.md @@ -26,13 +26,13 @@ Percona Backup for MongoDB supports the following storage types: Percona Backup for MongoDB should work with other S3-compatible storages, but was only tested with the following ones: -* [Amazon Simple Storage Service](https://docs.aws.amazon.com/s3/index.html) +* [Amazon Simple Storage Service :octicons-link-external-16:](https://docs.aws.amazon.com/s3/index.html) -* [Google Cloud Storage](https://cloud.google.com/storage) +* [Google Cloud Storage :octicons-link-external-16:](https://cloud.google.com/storage) -* [MinIO](https://min.io/) +* [MinIO :octicons-link-external-16:](https://min.io/) #### Server-side encryption @@ -73,8 +73,8 @@ serverSideEncryption: AWS Documentation: - * [Protecting Data Using Server-Side Encryption with CMKs Stored in AWS Key Management Service (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html) - * [Protecting data using server-side encryption with customer-provided encryption keys (SSE-C)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html) + * [Protecting Data Using Server-Side Encryption with CMKs Stored in AWS Key Management Service (SSE-KMS) :octicons-link-external-16:](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html) + * [Protecting data using server-side encryption with customer-provided encryption keys (SSE-C) :octicons-link-external-16:](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html) #### Debug logging @@ -88,7 +88,7 @@ To enable S3 debug logging, set the `storage.s3.DebugLogLevel` option in Percona !!! admonition "Version added: [1.7.0](../release-notes/1.7.0.md)" -Percona Backup for MongoDB supports [Amazon S3 storage classes](https://aws.amazon.com/s3/storage-classes/). Knowing your data access patterns, you can set the S3 storage class in Percona Backup for MongoDB configuration. When Percona Backup for MongoDB uploads data to S3, the data is distributed to the corresponding storage class. The support of S3 bucket storage types allows you to effectively manage S3 storage space and costs. +Percona Backup for MongoDB supports [Amazon S3 storage classes :octicons-link-external-16:](https://aws.amazon.com/s3/storage-classes/). Knowing your data access patterns, you can set the S3 storage class in Percona Backup for MongoDB configuration. When Percona Backup for MongoDB uploads data to S3, the data is distributed to the corresponding storage class. The support of S3 bucket storage types allows you to effectively manage S3 storage space and costs. To set the storage class, specify the `storage.s3.storageClass` option in Percona Backup for MongoDB configuration file @@ -150,7 +150,7 @@ This cannot be used except if you have a single-node replica set. (See the warni !!! admonition "Version added: [1.5.0](../release-notes/1.5.0.md)" -You can use [Microsoft Azure Blob Storage](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction) as the remote backup storage for Percona Backup for MongoDB. +You can use [Microsoft Azure Blob Storage :octicons-link-external-16:](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction) as the remote backup storage for Percona Backup for MongoDB. This gives users a vendor choice. Companies with Microsoft-based infrastructure can set up Percona Backup for MongoDB with less administrative efforts. @@ -190,9 +190,9 @@ Please refer to the documentation of your selected storage for the data access m !!! admonition "See also" - * AWS documentation: [Controlling access to a bucket with user policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html) - * Google Cloud Storage documentation: [Overview of access control](https://cloud.google.com/storage/docs/access-control) - * Microsoft Azure documentation: [Assign an Azure role for access to blob data](https://docs.microsoft.com/en-us/azure/storage/blobs/assign-azure-role-data-access?tabs=portal) - * MinIO documentation: [Policy Management](https://docs.min.io/minio/baremetal/security/minio-identity-management/policy-based-access-control.html) + * AWS documentation: [Controlling access to a bucket with user policies :octicons-link-external-16:](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html) + * Google Cloud Storage documentation: [Overview of access control :octicons-link-external-16:](https://cloud.google.com/storage/docs/access-control) + * Microsoft Azure documentation: [Assign an Azure role for access to blob data :octicons-link-external-16:](https://docs.microsoft.com/en-us/azure/storage/blobs/assign-azure-role-data-access?tabs=portal) + * MinIO documentation: [Policy Management :octicons-link-external-16:](https://docs.min.io/minio/baremetal/security/minio-identity-management/policy-based-access-control.html) *[AWS KMS]: Amazon Web Services Key Management Service \ No newline at end of file diff --git a/docs/details/versions.md b/docs/details/versions.md index 8464ad95..b0f90c3e 100644 --- a/docs/details/versions.md +++ b/docs/details/versions.md @@ -4,7 +4,7 @@ Percona Backup for MongoDB is compatible with the following MongoDB versions: | PBM version | MongoDB Community / Enterprise | Percona Server for MongoDB| | ----------- |------------------------------- | ------------------------- | -| [2.3.0](../release-notes/2.3.0.md) | Logical backups - version 4.4 and higher with [MongoDB Replication](https://docs.mongodb.com/manual/replication/) enabled| - Logical backups - version 4.4 and higher
- Physical backups - version 4.4.6-8, 5.0 and higher with [MongoDB Replication](https://docs.mongodb.com/manual/replication/) enabled and WiredTiger configured as the storage engine.| -| [1.7.0](../release-notes/1.7.0.md) | Logical backups - version 4.2 and higher with [MongoDB Replication](https://docs.mongodb.com/manual/replication/) enabled| - Logical backups - version 4.2 and higher
- Physical backups (tech preview) - version 4.2.15-16, 4.4.6-8, 5.0 and higher with [MongoDB Replication](https://docs.mongodb.com/manual/replication/) enabled and WiredTiger configured as the storage engine. -| [1.6.1](../release-notes/1.6.1.md) | Logical backups - version 3.6 and higher with [MongoDB Replication](https://docs.mongodb.com/manual/replication/) enabled| Logical backups - version 3.6 and higher| +| [2.3.0](../release-notes/2.3.0.md) | Logical backups - version 4.4 and higher with [MongoDB Replication :octicons-link-external-16:](https://docs.mongodb.com/manual/replication/) enabled| - Logical backups - version 4.4 and higher
- Physical backups - version 4.4.6-8, 5.0 and higher with [MongoDB Replication :octicons-link-external-16:](https://docs.mongodb.com/manual/replication/) enabled and WiredTiger configured as the storage engine.| +| [1.7.0](../release-notes/1.7.0.md) | Logical backups - version 4.2 and higher with [MongoDB Replication :octicons-link-external-16:](https://docs.mongodb.com/manual/replication/) enabled| - Logical backups - version 4.2 and higher
- Physical backups (tech preview) - version 4.2.15-16, 4.4.6-8, 5.0 and higher with [MongoDB Replication :octicons-link-external-16:](https://docs.mongodb.com/manual/replication/) enabled and WiredTiger configured as the storage engine. +| [1.6.1](../release-notes/1.6.1.md) | Logical backups - version 3.6 and higher with [MongoDB Replication :octicons-link-external-16:](https://docs.mongodb.com/manual/replication/) enabled| Logical backups - version 3.6 and higher| diff --git a/docs/features/comparison.md b/docs/features/comparison.md index ed04762e..41aa21d2 100644 --- a/docs/features/comparison.md +++ b/docs/features/comparison.md @@ -16,7 +16,7 @@ Percona Backup for MongoDB is a fully supported community backup solution that c * [Enterprise features without extra costs](comparison.md) * [Works for both sharded clusters and non-sharded replica sets](../details/deployments.md) -* [Simple command-line management utility](../reference/pbm-commands.md). For backup management via a user interface, consider [using PBM through Percona Monitoring and Management](https://docs.percona.com/percona-monitoring-and-management/get-started/backup/index.html) +* [Simple command-line management utility](../reference/pbm-commands.md). For backup management via a user interface, consider [using PBM through Percona Monitoring and Managemen :octicons-link-external-16:](https://docs.percona.com/percona-monitoring-and-management/get-started/backup/index.html) * Simple, [integrated-with-MongoDB authentication](../install/initial-setup.md#external-authentication-support-in-percona-backup-for-mongodb) * Distributed transaction consistency with MongoDB 4.2+ * Compatibility with different storage types: [S3-compatible storage](../details/storage-configuration.md#s3-compatible-storage), [Microsoft Azure Blob storage](../details/storage-configuration.md#microsoft-azure-blob-storage), `filesystem` storage type for [locally-mounted remote filesystem backup servers](../details/storage-configuration.md#remote-filesystem-server-storage) \ No newline at end of file diff --git a/docs/features/incremental-backup.md b/docs/features/incremental-backup.md index 6584d2b8..afc9ceb7 100644 --- a/docs/features/incremental-backup.md +++ b/docs/features/incremental-backup.md @@ -8,9 +8,9 @@ We recommend to make a new incremental base backup and start the incremental backup chain from it after the upgrade to Percona Backup for MongoDB 2.1.0 -* Incremental backup implementation is based on the [`$backupCursor`](https://docs.percona.com/percona-server-for-mongodb/6.0/backup-cursor.html) aggregation stage that is available only in Percona Server for MongoDB. Therefore, you must be running Percona Server for MongoDB in your deployment to use incremental physical backups. -* Incremental backups are supported for Percona Server for MongoDB starting with the following versions: [4.2.24-24](https://docs.percona.com/percona-server-for-mongodb/4.2/release_notes/4.2.24-24.html), [4.4.18](https://docs.percona.com/percona-server-for-mongodb/4.4/release_notes/4.4.18-18.html), [5.0.14-12](https://docs.percona.com/percona-server-for-mongodb/5.0/release_notes/5.0.14-12.html), [6.0.3-2](https://docs.percona.com/percona-server-for-mongodb/6.0/release_notes/6.0.3-2.html) and higher. -* Due to [WiredTger restrictions in Log-Structured Merge (LSM) trees](https://source.wiredtiger.com/develop/backup.html#backup_incremental-block) behavior when the `$backupCursor` is opened, incremental backups are not available if the LSM tree is configured in the database. +* Incremental backup implementation is based on the [`$backupCursor` :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/backup-cursor.html) aggregation stage that is available only in Percona Server for MongoDB. Therefore, you must be running Percona Server for MongoDB in your deployment to use incremental physical backups. +* Incremental backups are supported for Percona Server for MongoDB starting with the following versions: [4.2.24-24 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/4.2/release_notes/4.2.24-24.html), [4.4.18 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/4.4/release_notes/4.4.18-18.html), [5.0.14-12 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/5.0/release_notes/5.0.14-12.html), [6.0.3-2 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/6.0/release_notes/6.0.3-2.html) and higher. +* Due to [WiredTger restrictions in Log-Structured Merge (LSM) trees :octicons-link-external-16:](https://source.wiredtiger.com/develop/backup.html#backup_incremental-block) behavior when the `$backupCursor` is opened, incremental backups are not available if the LSM tree is configured in the database. Owners of large datasets may need to back up data frequently. Making full physical backups every time is costly in terms of storage space. Incremental physical backups come in handy in this scenario, enabling you to optimize backup strategy and reduce storage costs. diff --git a/docs/features/physical.md b/docs/features/physical.md index b983aa55..2f59bce8 100644 --- a/docs/features/physical.md +++ b/docs/features/physical.md @@ -5,14 +5,14 @@ ## Availability and system requirements * Percona Server for MongoDB starting from versions 4.2.15-16, 4.4.6-8, 5.0 and higher. -* WiredTiger is used as the storage engine in Percona Server for MongoDB, since physical backups heavily rely on the WiredTiger [`$backupCursor`](https://docs.percona.com/percona-server-for-mongodb/6.0/backup-cursor.html) functionality. +* WiredTiger is used as the storage engine in Percona Server for MongoDB, since physical backups heavily rely on the WiredTiger [`$backupCursor` :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/6.0/backup-cursor.html) functionality. !!! admonition "See also" Percona Blog - * [Physical Backup Support in Percona Backup for MongoDB](https://www.percona.com/blog/physical-backup-support-in-percona-backup-for-mongodb/) - * [$backupCursorExtend in Percona Server for MongoDB](https://www.percona.com/blog/2021/06/07/experimental-feature-backupcursorextend-in-percona-server-for-mongodb/) + * [Physical Backup Support in Percona Backup for MongoDB :octicons-link-external-16:](https://www.percona.com/blog/physical-backup-support-in-percona-backup-for-mongodb/) + * [$backupCursorExtend in Percona Server for MongoDB :octicons-link-external-16:](https://www.percona.com/blog/2021/06/07/experimental-feature-backupcursorextend-in-percona-server-for-mongodb/) Physical backup is copying of physical files from the Percona Server for MongoDB `dbPath` data directory to the remote backup storage. These files include data files, journal, index files, etc. Starting with version 2.0.0, Percona Backup for MongoDB also copies the WiredTiger storage options to the backup’s metadata. @@ -41,7 +41,7 @@ You may run both MongoDB Community / Enterprise Edition nodes and Percona Server You can make a physical, incremental or a snapshot-based backup in such a mixed deployment using PBM. This saves you from having to reconfigure your deployment for a backup, and keeps both your migration and backup strategies intact. -Physical, incremental and snapshot-based backups are only possible from PSMDB nodes since their implementation is based on the [`$backupCursorExtend`](https://docs.percona.com/percona-server-for-mongodb/latest/backup-cursor.html) functionality. When it’s time to make a backup, PBM searches the PSMDB node and makes a backup from it. The PSMDB node must not be an arbiter nor a delayed node. +Physical, incremental and snapshot-based backups are only possible from PSMDB nodes since their implementation is based on the [`$backupCursorExtend` :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/backup-cursor.html) functionality. When it’s time to make a backup, PBM searches the PSMDB node and makes a backup from it. The PSMDB node must not be an arbiter nor a delayed node. If more than 2 nodes are suitable for a backup, PBM selects the one with a higher [priority](../usage/start-backup.md#adjust-node-priority-for-backups). Note that if you override a priority for at least one node, PBM assigns priority `1.0` for the remaining nodes and uses the new priority list . @@ -64,7 +64,7 @@ During a backup, Percona Backup for MongoDB stores the encryption settings in th Make sure that you know what master encryption key was used and store it, as this key is required for the restore. -Starting with [Percona Server for MongoDB version 4.4.19-19](https://docs.percona.com/percona-server-for-mongodb/4.4/release_notes/4.4.19-19.html), [5.0.15-13](https://docs.percona.com/percona-server-for-mongodb/5.0/release_notes/5.0.15-13.html), [6.0.5-4](https://docs.percona.com/percona-server-for-mongodb/6.0/release_notes/6.0.5-4.html) and higher, the master key rotation for data-at-rest encrypted with HashiCorp Vault has been improved to use the same secret key path on every server in your entire deployment. For the restore with earlier versions of Percona Server for MongoDB and PBM 2.0.5 and earlier, see the [Restore for Percona Server for MongoDB **before** 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault](#restore-for-percona-server-for-mongodb-before-4419-19-5015-13-605-4-using-hashicorpvault) section. +Starting with [Percona Server for MongoDB version 4.4.19-19 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/4.4/release_notes/4.4.19-19.html), [5.0.15-13 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/5.0/release_notes/5.0.15-13.html), [6.0.5-4 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/6.0/release_notes/6.0.5-4.html) and higher, the master key rotation for data-at-rest encrypted with HashiCorp Vault has been improved to use the same secret key path on every server in your entire deployment. For the restore with earlier versions of Percona Server for MongoDB and PBM 2.0.5 and earlier, see the [Restore for Percona Server for MongoDB **before** 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault](#restore-for-percona-server-for-mongodb-before-4419-19-5015-13-605-4-using-hashicorpvault) section. To restore the encrypted data from the backup, configure data-at-rest encryption settings on all nodes of your destination cluster or replica set to match the settings of the target cluster where you made the backup @@ -72,8 +72,8 @@ During the restore, Percona Backup for MongoDB restores the data all nodes using To learn more about master key rotation, refer to the following documentation: -* [Master key rotation in HashiCorp Vault server](https://docs.percona.com/percona-server-for-mongodb/6.0/vault.html#key-rotation) -* [KMIP master key rotation](https://www.mongodb.com/docs/manual/tutorial/rotate-encryption-key/#kmip-master-key-rotation) +* [Master key rotation in HashiCorp Vault server :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/6.0/vault.html#key-rotation) +* [KMIP master key rotation :octicons-link-external-16:](https://www.mongodb.com/docs/manual/tutorial/rotate-encryption-key/#kmip-master-key-rotation) ### Restore for Percona Server for MongoDB **before** 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault diff --git a/docs/features/point-in-time-recovery.md b/docs/features/point-in-time-recovery.md index 9701525f..520ef1cd 100644 --- a/docs/features/point-in-time-recovery.md +++ b/docs/features/point-in-time-recovery.md @@ -12,13 +12,13 @@ Point-in-time recovery is restoring a database up to a specific timestamp. This Set the `pitr.enabled` configuration option to `true`. -=== "Command line" +=== ":octicons-file-code-24: Command line" ```{.bash data-prompt="$"} $ pbm config --set pitr.enabled=true ``` -=== "Configuration file" +=== ":material-console: Configuration file" ```yaml pitr: @@ -34,12 +34,12 @@ The `pbm-agent` starts [saving consecutive slices of the oplog](#oplog-slicing) To start saving [oplog slices](../reference/glossary.md#oplog), the following preconditions must be met: -=== "Logical backups" +=== ":material-data-matrix: Logical backups" * A full backup snapshot is required. Starting with version [2.3.0](../release-notes/2.3.0.md), it can be a logical, a physical or an incremental backup. Make sure that a [backup exists](../usage/list-backup.md). See the [Make a backup](../usage/start-backup.md) guide to make a backup snapshot. * Point-in-time recovery routine is [enabled](#enable-point-in-time-recovery). -=== "Physical backups" +=== ":material-database-refresh-outline: Physical backups" Point-in-time recovery routine is [enabled](#enable-point-in-time-recovery). @@ -50,7 +50,7 @@ If you just enabled point-in-time recovery, it requires 10 minutes for the first **For in MongoDB 5.0 and higher versions** - If you [reshard](https://www.mongodb.com/docs/manual/core/sharding-reshard-a-collection/) a collection, make a fresh backup and re-enable point-in-time recovery oplog slicing to prevent data inconsistency and restore failure. + If you [reshard :octicons-link-external-16:](https://www.mongodb.com/docs/manual/core/sharding-reshard-a-collection/) a collection, make a fresh backup and re-enable point-in-time recovery oplog slicing to prevent data inconsistency and restore failure. Starting with version [2.4.0](../release-notes/2.4.0.md), oplog slicing runs in parallel with a backup snapshot operation. Thereby if a backup snapshot is large and takes hours to make, all oplog events are saved for it ensuring point-in-time recovery to any timestamp. @@ -62,13 +62,13 @@ By default, a slice covers a 10-minute span of oplog events. It can be shorter i You can change the duration of an oplog span via the configuration file. Specify the new value (in minutes) for the `pitr.oplogSpanMin` option. -=== "Command line" +=== ":octicons-file-code-24: Command line" ```{.bash data-prompt="$"} $ pbm config --set pitr.oplogSpanMin=5 ``` -=== "Configuration file" +=== ":material-console: Configuration file" ```yaml pitr: @@ -85,13 +85,13 @@ If the new duration is shorter, this triggers the `pbm-agent` to make a new slic The oplog slices are saved with the `s2` compression method by default. You can specify a different compression method via the configuration file. Specify the new value for the [`pitr.compression`](../reference/pitr-options.md#pitrcompression) option. -=== "Command line" +=== ":octicons-file-code-24: Command line" ```{.bash data-prompt="$"} $ pbm config --set pitr.compression=gzip ``` -=== "Configuration file" +=== ":material-console: Configuration file" ```yaml pitr: diff --git a/docs/features/snapshots.md b/docs/features/snapshots.md index 35dcca98..c874463a 100644 --- a/docs/features/snapshots.md +++ b/docs/features/snapshots.md @@ -6,7 +6,7 @@ 1. This is a [technical preview feature](../reference/glossary.md#technical-preview-feature). 2. Supported only for full physical backups -3. Available only if you run Percona Server for MongoDB in your environment as PBM uses the [`$backupCursor and $backupCursorExtended aggregation stages`](https://docs.percona.com/percona-server-for-mongodb/6.0/backup-cursor.html). +3. Available only if you run Percona Server for MongoDB in your environment as PBM uses the [`$backupCursor and $backupCursorExtended aggregation stages` :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/backup-cursor.html). While a physical backup is a physical copy of your data directory, a snapshot is a point in time copy of your disk or a volume where the data files are stored. Restoring from snapshots is much faster and allows almost immediate access to data, while the database is unavailable during physical restore. Snapshot-based backups are especially useful for owners of large data sets with terabytes of data. Yet the snapshots don’t guarantee data consistency in sharded clusters. @@ -118,7 +118,7 @@ After the restore is complete, do the following: 5. Make a fresh backup to serve as the new base for future restores. -### Restore form a backup made outside PBM +### Restore from a backup made outside PBM !!! important @@ -126,7 +126,7 @@ After the restore is complete, do the following: To restore an external backup made outside PBM, you need to specify the following for the `pbm restore` command: -* a path to the configuration file of the `mongod` node on the source cluster from where the backup was made. This is the configuration file that PBM uses during the restore. It should contain the [storage options](https://www.mongodb.com/docs/manual/reference/configuration-options/#storage-options ) per replica set name, for example: +* a path to the configuration file of the `mongod` node on the source cluster from where the backup was made. This is the configuration file that PBM uses during the restore. It should contain the [storage options :octicons-link-external-16:](https://www.mongodb.com/docs/manual/reference/configuration-options/#storage-options ) per replica set name, for example: ```yaml rs1: @@ -171,6 +171,6 @@ To restore from a backup, do the following: $ sudo -u mongod -s pbm restore-finish -c --mongodb-uri=MONGODB_URI ``` -4. Don't forget to complete the [post-restore steps](#post-restore-steps) +4. Don't forget to complete the [post-restore steps](#post-restore-steps). diff --git a/docs/index.md b/docs/index.md index de411052..9375c51f 100644 --- a/docs/index.md +++ b/docs/index.md @@ -2,7 +2,7 @@ Percona Backup for MongoDB (PBM) is an open source and distributed solution for consistent backups and restore of [MongoDB sharded clusters and replica sets](details/deployments.md). Read more [how PBM works](intro.md). -Make backups on a running server and restore your database to a specific point in time using the PBM command line interface. Alternatively, manage backups from a web interface [with PBM and Percona Monitoring and Management](https://docs.percona.com/percona-monitoring-and-management/get-started/backup/index.html). +Make backups on a running server and restore your database to a specific point in time using the PBM command line interface. Alternatively, manage backups from a web interface [with PBM and Percona Monitoring and Management :octicons-link-external-16:](https://docs.percona.com/percona-monitoring-and-management/get-started/backup/index.html). !!! note "" diff --git a/docs/install/configure-authentication.md b/docs/install/configure-authentication.md index b20bfaea..9f675bdc 100644 --- a/docs/install/configure-authentication.md +++ b/docs/install/configure-authentication.md @@ -89,7 +89,7 @@ The `pbm-agent.service` systemd unit file includes the environment file. You set WantedBy=multi-user.target ``` -=== "On Debian and Ubuntu Linux" +=== ":material-debian: On Debian and Ubuntu" Edit the environment file `/etc/default/pbm-agent` and specify the MongoDB connection URI string for the `pbm` user to the local `mongod` node. @@ -99,7 +99,7 @@ The `pbm-agent.service` systemd unit file includes the environment file. You set PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@localhost:27017/?authSource=admin" ``` -=== "On Red Hat Enterprise Linux and derivatives" +=== ":material-redhat: On Red Hat Enterprise Linux and derivatives" Edit the environment file `/etc/sysconfig/pbm-agent` and specify the MongoDB connection URI string for the `pbm` user to the local `mongod` node. @@ -133,11 +133,11 @@ For more information about what connection string to specify, refer to the [pbm ## External authentication support in Percona Backup for MongoDB -In addition to SCRAM, Percona Backup for MongoDB supports other [authentication methods](https://docs.percona.com/percona-server-for-mongodb/latest/authentication.html) that you use in MongoDB or Percona Server for MongoDB. +In addition to SCRAM, Percona Backup for MongoDB supports other [authentication methods :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/authentication.html) that you use in MongoDB or Percona Server for MongoDB. For external authentication, you create the `pbm` user in the format used by the authentication system and set the MongoDB connection URI string to include both the authentication method and authentication source. -For example, for [Kerberos authentication](https://docs.percona.com/percona-server-for-mongodb/6.0/authentication.html#kerberos-authentication), create the `pbm` user in the `$external` database in the format `` (e.g. [pbm@PERCONATEST.COM](mailto:pbm@PERCONATEST.COM)). +For example, for [Kerberos authentication :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/authentication.html#kerberos-authentication), create the `pbm` user in the `$external` database in the format `` (e.g. [pbm@PERCONATEST.COM](mailto:pbm@PERCONATEST.COM)). Specify the following string for MongoDB connection URI: @@ -153,22 +153,22 @@ $ sudo -u {USER} kinit pbm Note that the `{USER}` is the user that you will run the `pbm-agent` process. -For [authentication and authorization via Native LDAP](https://docs.percona.com/percona-server-for-mongodb/6.0/authorization.html#authentication-and-authorization-with-direct-binding-to-ldap), you only create roles for LDAP groups in MongoDB as the users are stored and managed on the LDAP server. However, you still define the `$external` database as your authentication source: +For [authentication and authorization via Native LDAP :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/authorization.html#authentication-and-authorization-with-direct-binding-to-ldap), you only create roles for LDAP groups in MongoDB as the users are stored and managed on the LDAP server. However, you still define the `$external` database as your authentication source: ``` PBM_MONGODB_URI="mongodb://:@:27017/?authMechanism=PLAIN&authSource=%24external&replSetName=xxxx" ``` -When using [AWS IAM authentication](), create the `pbm` user in the `$external` database with the username that contains the ARN of the IAM user/role. +When using [AWS IAM authentication :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/aws-iam.html), create the `pbm` user in the `$external` database with the username that contains the ARN of the IAM user/role. -=== "User authentication" +=== ":fontawesome-regular-user: User authentication" ``` arn:aws:iam:::user/ ``` -=== "Role authentication" +=== ":material-cloud-key-outline: Role authentication" ``` arn:aws:iam:::role/ diff --git a/docs/install/docker.md b/docs/install/docker.md index 86d182fe..38000700 100644 --- a/docs/install/docker.md +++ b/docs/install/docker.md @@ -1,8 +1,8 @@ # Run Percona Backup for MongoDB in a Docker container -Docker images of Percona Backup for MongoDB are hosted publicly on [Docker Hub](https://hub.docker.com/repository/docker/percona/percona-backup-mongodb). +Docker images of Percona Backup for MongoDB are hosted publicly on [Docker Hub :octicons-link-external-16:](https://hub.docker.com/repository/docker/percona/percona-backup-mongodb). -For more information about using Docker, see the [Docker Docs](https://docs.docker.com/). +For more information about using Docker, see the [Docker Docs :octicons-link-external-16:](https://docs.docker.com/). !!! note @@ -27,7 +27,7 @@ $ docker run --name -e PBM_MONGODB_URI="mongodb://:

` with the required version. diff --git a/docs/installation.md b/docs/installation.md index fc553556..f9b6d770 100644 --- a/docs/installation.md +++ b/docs/installation.md @@ -2,7 +2,7 @@ Percona Backup for MongoDB (PBM) is an open source and distributed solution for consistent backups and restore of [MongoDB sharded clusters and replica sets](details/deployments.md). [Learn how PBM works](intro.md). -Find the list of supported platforms for Percona Backup for MongoDB on the [Percona Software and Platform Lifecycle](https://www.percona.com/services/policies/percona-software-platform-lifecycle#mongodb) page. +Find the list of supported platforms for Percona Backup for MongoDB on the [Percona Software and Platform Lifecycle :octicons-link-external-16:](https://www.percona.com/services/policies/percona-software-platform-lifecycle#mongodb) page. ## System requirements diff --git a/docs/manage/automate-s3-access.md b/docs/manage/automate-s3-access.md index 0a1db4d8..f318ce85 100644 --- a/docs/manage/automate-s3-access.md +++ b/docs/manage/automate-s3-access.md @@ -10,7 +10,7 @@ IAM (Identity Access Management) is the AWS service that allows you to securely Using the IAM instance profile, you can automate access to S3 buckets for Percona Backup for MongoDB running on EC2 instance. The steps are the following: -1. Create the [IAM instance profile](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) and the permission policy within where you specify the access level that grants the access to S3 buckets. +1. Create the [IAM instance profile :octicons-link-external-16:](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) and the permission policy within where you specify the access level that grants the access to S3 buckets. 2. Attach the IAM profile to an EC2 instance. @@ -36,17 +36,17 @@ Using the IAM instance profile, you can automate access to S3 buckets for Percon !!! admonition "See also" - AWS documentation: [How can I grant my Amazon EC2 instance access to an Amazon S3 bucket?](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-access-s3-bucket/) + AWS documentation: [How can I grant my Amazon EC2 instance access to an Amazon S3 bucket? :octicons-link-external-16:](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-access-s3-bucket/) ## IAM Roles for Service Accounts (IRSA) !!! admonition "Version added: 2.0.3" -[IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) is the native way for AWS EKS (Amazon Elastic Kubernetes Service) to allow applications running in EKS pods to access the AWS API using permissions configured in AWS IAM roles. +[IRSA :octicons-link-external-16:](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) is the native way for AWS EKS (Amazon Elastic Kubernetes Service) to allow applications running in EKS pods to access the AWS API using permissions configured in AWS IAM roles. To benefit from using the AWS IRSA credentials with PBM, the high-level steps are the following: -1. [Create a cluster](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-eks-cluster.html) with `eksctl` and OIDC provider setup enabled. This feature works with EKS clusters version 1.13 and above. +1. [Create a cluster :octicons-link-external-16:](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-eks-cluster.html) with `eksctl` and OIDC provider setup enabled. This feature works with EKS clusters version 1.13 and above. 2. Create an IAM role and specify the policy that defines the access to an S3 bucket. 3. Create a service account and annotate it with the IAM role. 3. Configure your pod by using the service account created in the previous step and assume the IAM role. @@ -61,8 +61,8 @@ To benefit from using the AWS IRSA credentials with PBM, the high-level steps ar AWS documentation: - * [Introducing fine-grained IAM roles for service accounts](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) - * [How do I use the IAM roles for service accounts (IRSA) feature with Amazon EKS to restrict access to an Amazon S3 bucket?](https://aws.amazon.com/premiumsupport/knowledge-center/eks-restrict-s3-bucket/) + * [Introducing fine-grained IAM roles for service accounts :octicons-link-external-16:](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) + * [How do I use the IAM roles for service accounts (IRSA) feature with Amazon EKS to restrict access to an Amazon S3 bucket? :octicons-link-external-16:](https://aws.amazon.com/premiumsupport/knowledge-center/eks-restrict-s3-bucket/) diff --git a/docs/manage/upgrading.md b/docs/manage/upgrading.md index d9df75ed..e77ec2dc 100644 --- a/docs/manage/upgrading.md +++ b/docs/manage/upgrading.md @@ -20,9 +20,7 @@ The recommended and most convenient way to upgrade PBM is from Percona repositor ## Prerequisites -Run all commands as root or via `sudo`. - -1. [Install `percona-release` tool](https://www.percona.com/doc/percona-repo-config/installing.html). If you have installed it before, [update](https://www.percona.com/doc/percona-repo-config/updating.html) it to the latest version. +1. [Install `percona-release` tool :octicons-link-external-16:](https://www.percona.com/doc/percona-repo-config/installing.html) or [update it :octicons-link-external-16:](https://www.percona.com/doc/percona-repo-config/updating.html) to the latest version. 2. Enable the repository @@ -30,169 +28,175 @@ Run all commands as root or via `sudo`. $ sudo percona-release enable pbm release ``` -!!! note - - For `apt`-based systems, run `sudo apt update` to update the local cache. +:material-information: Note: For `apt`-based systems, run `sudo apt update` to update the local cache. ## Upgrade to the latest version -=== "On Debian and Ubuntu Linux" +=== ":material-debian: On Debian and Ubuntu Linux" - ### 1. Stop `pbm-agent` + Run all commands as root or via `sudo`. + {.power-number} - ```{.bash data-prompt="$"} - $ sudo systemctl stop pbm-agent - ``` + 1. Stop `pbm-agent` - ### 2. Install new packages + ```{.bash data-prompt="$"} + $ sudo systemctl stop pbm-agent + ``` - ```{.bash data-prompt="$"} - $ sudo apt install percona-backup-mongodb - ``` + 2. Install new packages - ### 3. Reload the `systemd` process + ```{.bash data-prompt="$"} + $ sudo apt install percona-backup-mongodb + ``` - Starting from v1.7.0, reload the `systemd` process to update the unit file with the following command: + 3. Reload the `systemd` process - ```{.bash data-prompt="$"} - $ sudo systemctl daemon-reload - ``` + Starting from v1.7.0, reload the `systemd` process to update the unit file with the following command: - ### 4. Update permissions + ```{.bash data-prompt="$"} + $ sudo systemctl daemon-reload + ``` - For a *filesystem-based backup storage*, grant read / write permissions to the backup directory to the `mongod` user. + 4. Update permissions + For a *filesystem-based backup storage*, grant read / write permissions to the backup directory to the `mongod` user. - ### 5. Start `pbm-agent` - ```{.bash data-prompt="$"} - $ sudo systemctl start pbm-agent - ``` + 5. Start `pbm-agent` -=== "On Red Hat Enterprise Linux and derivatives" + ```{.bash data-prompt="$"} + $ sudo systemctl start pbm-agent + ``` - ### 1. Stop `pbm-agent` +=== ":material-redhat: On Red Hat Enterprise Linux and derivatives" - ```{.bash data-prompt="$"} - $ sudo systemctl stop pbm-agent - ``` + Run all commands as root or via `sudo`. + {.power-number} - ### 2. Install new packages + 1. Stop `pbm-agent` - ```{.bash data-prompt="$"} - $ sudo yum install percona-backup-mongodb - ``` + ```{.bash data-prompt="$"} + $ sudo systemctl stop pbm-agent + ``` - ### 3. Reload the `systemd` process + 2. Install new packages - Starting from v1.7.0, reload the `systemd` process to update the unit file with the following command: + ```{.bash data-prompt="$"} + $ sudo yum install percona-backup-mongodb + ``` - ```{.bash data-prompt="$"} - $ sudo systemctl daemon-reload - ``` + 3. Reload the `systemd` process - ### 4. Update permissions + Starting from v1.7.0, reload the `systemd` process to update the unit file with the following command: + + ```{.bash data-prompt="$"} + $ sudo systemctl daemon-reload + ``` - For a *filesystem-based backup storage*, grant read / write permissions to the backup directory to the `mongod` user. + 4. Update permissions + For a *filesystem-based backup storage*, grant read / write permissions to the backup directory to the `mongod` user. - ### 5. Start `pbm-agent` + 5. Start `pbm-agent` - ```{.bash data-prompt="$"} - $ sudo systemctl start pbm-agent - ``` + ```{.bash data-prompt="$"} + $ sudo systemctl start pbm-agent + ``` ## Upgrade to a specific version -=== "On Debian and Ubuntu Linux" +=== ":material-debian: On Debian and Ubuntu Linux" - ### 1. List available versions + Run all commands as root or via `sudo`. + {.power-number} - ```{.bash data-prompt="$"} - $ sudo apt-cache madison percona-backup-mongodb - ``` + 1. List available versions + + ```{.bash data-prompt="$"} + $ sudo apt-cache madison percona-backup-mongodb + ``` - Output: + ??? example "Sample output" - ```{.text .no-copy} - percona-backup-mongodb | 1.8.1-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages - percona-backup-mongodb | 1.8.0-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages - percona-backup-mongodb | 1.7.0-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages - percona-backup-mongodb | 1.6.1-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages - percona-backup-mongodb | 1.6.0-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages - percona-backup-mongodb | 1.5.0-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages - ``` + ```{.text .no-copy} + percona-backup-mongodb | 1.8.1-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages + percona-backup-mongodb | 1.8.0-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages + percona-backup-mongodb | 1.7.0-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages + percona-backup-mongodb | 1.6.1-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages + percona-backup-mongodb | 1.6.0-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages + percona-backup-mongodb | 1.5.0-1.stretch | http://repo.percona.com/tools/apt stretch/main amd64 Packages + ``` - ### 2. Stop `pbm-agent` + 2. Stop `pbm-agent` - ```{.bash data-prompt="$"} - $ sudo systemctl stop pbm-agent - ``` + ```{.bash data-prompt="$"} + $ sudo systemctl stop pbm-agent + ``` - ### 3. Install packages + 3. Install packages - Install a specific version packages. For example, to upgrade to Percona Backup for MongoDB 1.7.0, run the following command: + Install a specific version packages. For example, to upgrade to Percona Backup for MongoDB 1.7.0, run the following command: - ```{.bash data-prompt="$"} - $ sudo apt install percona-backup-mongodb=1.7.0-1.stretch - ``` + ```{.bash data-prompt="$"} + $ sudo apt install percona-backup-mongodb=1.7.0-1.stretch + ``` - ### 4. Update permissions + 4. Update permissions - For a *filesystem-based backup storage*, grant read / write permissions to the backup directory to the `mongod` user. + For a *filesystem-based backup storage*, grant read / write permissions to the backup directory to the `mongod` user. - ### 5. Start `pbm-agent` - - ```{.bash data-prompt="$"} - $ sudo systemctl start pbm-agent - ``` + 5. Start `pbm-agent` + + ```{.bash data-prompt="$"} + $ sudo systemctl start pbm-agent + ``` -=== "On Red Hat Enterprise Linux and derivatives" +=== ":material-redhat: On Red Hat Enterprise Linux and derivatives" - ### 1. List available versions + Run all commands as root or via `sudo`. + {.power-number} - ```{.bash data-prompt="$"} - $ sudo yum list percona-backup-mongodb --showduplicates - ``` + 1. List available versions - Output: + ```{.bash data-prompt="$"} + $ sudo yum list percona-backup-mongodb --showduplicates + ``` - ```{.text .no-copy} - Available Packages - percona-backup-mongodb.x86_64 1.8-1.el7 pbm-release-x86_64 - percona-backup-mongodb.x86_64 1.8.0-1.el7 pbm-release-x86_64 - percona-backup-mongodb.x86_64 1.7.0-1.el7 pbm-release-x86_64 - percona-backup-mongodb.x86_64 1.6.1-1.el7 pbm-release-x86_64 - percona-backup-mongodb.x86_64 1.6.0-1.el7 pbm-release-x86_64 - percona-backup-mongodb.x86_64 1.5.0-1.el7 pbm-release-x86_64 - ``` + ??? example "Sample output" - ### 2. Stop `pbm-agent` + ```{.text .no-copy} + Available Packages + percona-backup-mongodb.x86_64 1.8-1.el7 pbm-release-x86_64 + percona-backup-mongodb.x86_64 1.8.0-1.el7 pbm-release-x86_64 + percona-backup-mongodb.x86_64 1.7.0-1.el7 pbm-release-x86_64 + percona-backup-mongodb.x86_64 1.6.1-1.el7 pbm-release-x86_64 + percona-backup-mongodb.x86_64 1.6.0-1.el7 pbm-release-x86_64 + percona-backup-mongodb.x86_64 1.5.0-1.el7 pbm-release-x86_64 + ``` - ```{.bash data-prompt="$"} - $ sudo systemctl stop pbm-agent - ``` + 2. Stop `pbm-agent` - ### 3. Install packages + ```{.bash data-prompt="$"} + $ sudo systemctl stop pbm-agent + ``` - Install a specific version packages. For example, to upgrade to Percona Backup for MongoDB 1.7.1, run the following command: + 3. Install packages - ```{.bash data-prompt="$"} - $ sudo yum install percona-backup-mongodb-1.7.1-1.el7 - ``` - - ### 4. Update permissions - - For a *filesystem-based backup storage*, grant read / write permissions to the backup directory to the `mongod` user. + Install a specific version packages. For example, to upgrade to Percona Backup for MongoDB 1.7.1, run the following command: + ```{.bash data-prompt="$"} + $ sudo yum install percona-backup-mongodb-1.7.1-1.el7 + ``` + + 4. Update permissions - ### 5. Start `pbm-agent` + For a *filesystem-based backup storage*, grant read / write permissions to the backup directory to the `mongod` user. - ```{.bash data-prompt="$"} - $ sudo systemctl start pbm-agent - ``` + 5. Start `pbm-agent` -!!! note + ```{.bash data-prompt="$"} + $ sudo systemctl start pbm-agent + ``` - If MongoDB runs under a *different user than `mongod`* (the default configuration for Percona Server for MongoDB), use the same user to run the `pbm-agent`. For filesystem-based storage, grant the read / write permissions to the backup directory for this user. +:material-information: Note: If MongoDB runs under a *different user than `mongod`* (the default configuration for Percona Server for MongoDB), use the same user to run the `pbm-agent`. For filesystem-based storage, grant the read / write permissions to the backup directory for this user. diff --git a/docs/pmm.md b/docs/pmm.md index b7be7d4d..22f8d9a1 100644 --- a/docs/pmm.md +++ b/docs/pmm.md @@ -1,11 +1,11 @@ # Backup management via Percona Monitoring and Management -You can manage backups not only via the command line, but also via the web interface using [Percona Monitoring and Management (PMM)](https://www.percona.com/doc/percona-monitoring-and-management/2.x/index.html). This way you don't have to manually run commands on multiple servers. Instead, you can schedule backups or run them on demand from a single place and also receive real-time monitoring alerts. +You can manage backups not only via the command line, but also via the web interface using [Percona Monitoring and Management (PMM) :octicons-link-external-16:](https://www.percona.com/doc/percona-monitoring-and-management/2.x/index.html). This way you don't have to manually run commands on multiple servers. Instead, you can schedule backups or run them on demand from a single place and also receive real-time monitoring alerts. Check PMM documentation for the following guides: -* [How to configure PMM to monitor MongoDB](https://docs.percona.com/percona-monitoring-and-management/setting-up/client/mongodb.html) -* [Backup management for MongoDB in PMM](https://docs.percona.com/percona-monitoring-and-management/get-started/backup/backup_mongo.html). +* [How to configure PMM to monitor MongoDB :octicons-link-external-16:](https://docs.percona.com/percona-monitoring-and-management/setting-up/client/mongodb.html) +* [Backup management for MongoDB in PMM :octicons-link-external-16:](https://docs.percona.com/percona-monitoring-and-management/get-started/backup/backup_mongo.html). diff --git a/docs/troubleshoot/status.md b/docs/troubleshoot/status.md index c317acf4..7eb3a065 100644 --- a/docs/troubleshoot/status.md +++ b/docs/troubleshoot/status.md @@ -22,47 +22,47 @@ The output provides the information about: This simplifies troubleshooting since the whole information is provided in one place. -**Sample output** - -```{.bash .no-copy} -pbm status - -Cluster: -======== -config: - - config/localhost:27027: pbm-agent v1.3.2 OK - - config/localhost:27028: pbm-agent v1.3.2 OK - - config/localhost:27029: pbm-agent v1.3.2 OK -rs1: - - rs1/localhost:27018: pbm-agent v1.3.2 OK - - rs1/localhost:27019: pbm-agent v1.3.2 OK - - rs1/localhost:27020: pbm-agent v1.3.2 OK -rs2: - - rs2/localhost:28018: pbm-agent v1.3.2 OK - - rs2/localhost:28019: pbm-agent v1.3.2 OK - - rs2/localhost:28020: pbm-agent v1.3.2 OK - -PITR incremental backup: -======================== -Status [OFF] - -Currently running: -================== -(none) - -Backups: -======== -S3 us-east-1 https://storage.googleapis.com/backup-test - Snapshots: - 2020-12-16T10:36:52Z 491.98KB [restore_to_time: 2020-12-16T10:37:13Z] - 2020-12-15T12:59:47Z 284.06KB [restore_to_time: 2020-12-15T13:00:08Z] - 2020-12-15T11:40:46Z 0.00B [canceled: 2020-12-15T11:41:07Z] - 2020-12-11T16:23:55Z 284.82KB [restore_to_time: 2020-12-11T16:24:16Z] - 2020-12-11T16:22:35Z 284.04KB [restore_to_time: 2020-12-11T16:22:56Z] - 2020-12-11T16:21:15Z 283.36KB [restore_to_time: 2020-12-11T16:21:36Z] - 2020-12-11T16:19:54Z 281.73KB [restore_to_time: 2020-12-11T16:20:15Z] - 2020-12-11T16:19:00Z 281.73KB [restore_to_time: 2020-12-11T16:19:21Z] - 2020-12-11T15:30:38Z 287.07KB [restore_to_time: 2020-12-11T15:30:59Z] -PITR chunks: - 2020-12-16T10:37:13 - 2020-12-16T10:43:26 44.17KB -``` \ No newline at end of file +??? example "Sample output" + + ```{.bash .no-copy} + pbm status + + Cluster: + ======== + config: + - config/localhost:27027: pbm-agent v1.3.2 OK + - config/localhost:27028: pbm-agent v1.3.2 OK + - config/localhost:27029: pbm-agent v1.3.2 OK + rs1: + - rs1/localhost:27018: pbm-agent v1.3.2 OK + - rs1/localhost:27019: pbm-agent v1.3.2 OK + - rs1/localhost:27020: pbm-agent v1.3.2 OK + rs2: + - rs2/localhost:28018: pbm-agent v1.3.2 OK + - rs2/localhost:28019: pbm-agent v1.3.2 OK + - rs2/localhost:28020: pbm-agent v1.3.2 OK + + PITR incremental backup: + ======================== + Status [OFF] + + Currently running: + ================== + (none) + + Backups: + ======== + S3 us-east-1 https://storage.googleapis.com/backup-test + Snapshots: + 2020-12-16T10:36:52Z 491.98KB [restore_to_time: 2020-12-16T10:37:13Z] + 2020-12-15T12:59:47Z 284.06KB [restore_to_time: 2020-12-15T13:00:08Z] + 2020-12-15T11:40:46Z 0.00B [canceled: 2020-12-15T11:41:07Z] + 2020-12-11T16:23:55Z 284.82KB [restore_to_time: 2020-12-11T16:24:16Z] + 2020-12-11T16:22:35Z 284.04KB [restore_to_time: 2020-12-11T16:22:56Z] + 2020-12-11T16:21:15Z 283.36KB [restore_to_time: 2020-12-11T16:21:36Z] + 2020-12-11T16:19:54Z 281.73KB [restore_to_time: 2020-12-11T16:20:15Z] + 2020-12-11T16:19:00Z 281.73KB [restore_to_time: 2020-12-11T16:19:21Z] + 2020-12-11T15:30:38Z 287.07KB [restore_to_time: 2020-12-11T15:30:59Z] + PITR chunks: + 2020-12-16T10:37:13 - 2020-12-16T10:43:26 44.17KB + ``` \ No newline at end of file diff --git a/docs/troubleshoot/troubleshooting.md b/docs/troubleshoot/troubleshooting.md index 2e2608f4..1b40fd12 100644 --- a/docs/troubleshoot/troubleshooting.md +++ b/docs/troubleshoot/troubleshooting.md @@ -21,13 +21,13 @@ Run **pbm-speed-test** for the full set of available commands. $ pbm-speed-test compression --compression=s2 --size-gb 10 ``` -Output: +??? example "Sample output" -```{.bash .no-copy} -Test started .... -10.00GB sent in 8s. -Avg upload rate = 1217.13MB/s. -``` + ```{.bash .no-copy} + Test started .... + 10.00GB sent in 8s. + Avg upload rate = 1217.13MB/s. + ``` **pbm-speed-test compression** uses the compression library from the config file and sends a fake semi random data document (1 GB by default) to the @@ -64,13 +64,13 @@ Flags: $ pbm-speed-test storage --compression=s2 ``` -Output +??? example "Sample output" -``` -Test started -1.00GB sent in 1s. -Avg upload rate = 1744.43MB/s. -``` + ``` + Test started + 1.00GB sent in 1s. + Avg upload rate = 1744.43MB/s. + ``` `pbm-speed-test storage` sends the semi random data (1 GB by default) to the remote storage defined in the config file. Pass the `--size-gb` flag to change the @@ -122,30 +122,30 @@ Check backup progress: $ journalctl -u pbm-agent.service ``` - Sample output: - - ``` {.bash .no-copy} - 2020/05/06 21:31:12 Backup 2020-05-06T18:31:12Z started on node rs2/localhost:28018 - 2020-05-06T21:31:14.797+0300 writing admin.system.users to archive on stdout - 2020-05-06T21:31:14.799+0300 done dumping admin.system.users (2 documents) - 2020-05-06T21:31:14.800+0300 writing admin.system.roles to archive on stdout - 2020-05-06T21:31:14.807+0300 done dumping admin.system.roles (1 document) - 2020-05-06T21:31:14.807+0300 writing admin.system.version to archive on stdout - 2020-05-06T21:31:14.815+0300 done dumping admin.system.version (3 documents) - 2020-05-06T21:31:14.816+0300 writing test.testt to archive on stdout - 2020-05-06T21:31:14.829+0300 writing test.testt2 to archive on stdout - 2020-05-06T21:31:14.829+0300 writing config.cache.chunks.config.system.sessions to archive on stdout - 2020-05-06T21:31:14.832+0300 done dumping config.cache.chunks.config.system.sessions (1 document) - 2020-05-06T21:31:14.834+0300 writing config.cache.collections to archive on stdout - 2020-05-06T21:31:14.835+0300 done dumping config.cache.collections (1 document) - 2020/05/06 21:31:24 [##......................] test.testt 130841/1073901 (12.2%) - 2020/05/06 21:31:24 [##########..............] test.testt2 131370/300000 (43.8%) - 2020/05/06 21:31:24 - 2020/05/06 21:31:34 [#####...................] test.testt 249603/1073901 (23.2%) - 2020/05/06 21:31:34 [###################.....] test.testt2 249603/300000 (83.2%) - 2020/05/06 21:31:34 - 2020/05/06 21:31:37 [########################] test.testt2 300000/300000 (100.0%) - ``` + ??? example "Sample output" + + ``` {.bash .no-copy} + 2020/05/06 21:31:12 Backup 2020-05-06T18:31:12Z started on node rs2/localhost:28018 + 2020-05-06T21:31:14.797+0300 writing admin.system.users to archive on stdout + 2020-05-06T21:31:14.799+0300 done dumping admin.system.users (2 documents) + 2020-05-06T21:31:14.800+0300 writing admin.system.roles to archive on stdout + 2020-05-06T21:31:14.807+0300 done dumping admin.system.roles (1 document) + 2020-05-06T21:31:14.807+0300 writing admin.system.version to archive on stdout + 2020-05-06T21:31:14.815+0300 done dumping admin.system.version (3 documents) + 2020-05-06T21:31:14.816+0300 writing test.testt to archive on stdout + 2020-05-06T21:31:14.829+0300 writing test.testt2 to archive on stdout + 2020-05-06T21:31:14.829+0300 writing config.cache.chunks.config.system.sessions to archive on stdout + 2020-05-06T21:31:14.832+0300 done dumping config.cache.chunks.config.system.sessions (1 document) + 2020-05-06T21:31:14.834+0300 writing config.cache.collections to archive on stdout + 2020-05-06T21:31:14.835+0300 done dumping config.cache.collections (1 document) + 2020/05/06 21:31:24 [##......................] test.testt 130841/1073901 (12.2%) + 2020/05/06 21:31:24 [##########..............] test.testt2 131370/300000 (43.8%) + 2020/05/06 21:31:24 + 2020/05/06 21:31:34 [#####...................] test.testt 249603/1073901 (23.2%) + 2020/05/06 21:31:34 [###################.....] test.testt2 249603/300000 (83.2%) + 2020/05/06 21:31:34 + 2020/05/06 21:31:37 [########################] test.testt2 300000/300000 (100.0%) + ``` ## `pbm-agent` logs diff --git a/docs/usage/delete-backup.md b/docs/usage/delete-backup.md index bac001cf..afe2b0e4 100644 --- a/docs/usage/delete-backup.md +++ b/docs/usage/delete-backup.md @@ -48,14 +48,14 @@ Here's how the cleanup works: This timestamp falls inside the backup chain that starts with the `2023-04-14T08:12:50Z` backup. That’s why PBM keeps this backup and the incremental backup chain deriving from it and deletes all data that is older than this backup. - Output: - - ```{.bash .no-copy} - S3 us-east-1 s3://http://192.168.56.1:9000/bcp/pbme2etest - Snapshots: - 2023-04-14T19:34:52Z 520.86MB [restore_to_time: 2023-04-14T19:34:54Z] - 2023-04-14T08:12:50Z 576.63MB [restore_to_time: 2023-04-14T08:12:52Z] - ``` + ??? example "Sample output" + + ```{.bash .no-copy} + S3 us-east-1 s3://http://192.168.56.1:9000/bcp/pbme2etest + Snapshots: + 2023-04-14T19:34:52Z 520.86MB [restore_to_time: 2023-04-14T19:34:54Z] + 2023-04-14T08:12:50Z 576.63MB [restore_to_time: 2023-04-14T08:12:52Z] + ``` * **Logical backup** cleanup also depends on the point-in-time recovery settings. @@ -76,6 +76,8 @@ Here's how the cleanup works: The most recent backup in relation to this timestamp is `2023-04-13T10:12:08Z 147.29MB`. So PBM deletes all backups that are older than this backup. It also deletes all oplog slices up to the backup’s `restore_to_time: 2023-04-13T10:12:27Z`. The output after the cleanup looks like this: + Sample output: + ```{.bash .no-copy} Snapshots: 2023-04-13T13:26:58Z 147.29MB [restore_to_time: 2023-04-13T13:27:15Z] @@ -132,7 +134,7 @@ Here's how the cleanup works: You can delete either a specified backup snapshot or all backup snapshots older than the specified time. Starting with version 2.0.0, you can also delete [selective backups](../features/selective-backup.md). -=== "A specific backup" +=== "Specified backup" To delete a backup, specify the `` as an argument. @@ -155,15 +157,15 @@ You can delete either a specified backup snapshot or all backup snapshots older $ pbm list ``` - **Output**: + ??? example "Sample output" - ```{.text .no-copy} - Backup snapshots: - 2021-04-20T20:55:42Z - 2021-04-20T23:47:34Z - 2021-04-20T23:53:20Z - 2021-04-21T02:16:33Z - ``` + ```{.text .no-copy} + Backup snapshots: + 2021-04-20T20:55:42Z + 2021-04-20T23:47:34Z + 2021-04-20T23:53:20Z + 2021-04-21T02:16:33Z + ``` Delete backups created before the specified timestamp @@ -171,12 +173,12 @@ You can delete either a specified backup snapshot or all backup snapshots older pbm delete-backup -f --older-than 2021-04-21 ``` - **Output**: + ??? example "Sample output" - ```{.text .no-copy} - Backup snapshots: - 2021-04-21T02:16:33Z - ``` + ```{.text .no-copy} + Backup snapshots: + 2021-04-21T02:16:33Z + ``` === "Specific types of backups" @@ -219,17 +221,19 @@ You can delete either a specified backup snapshot or all backup snapshots older The resulting list of backups looks like this: - ```{.text .no-copy} - Backups: - Snapshots: - 2024-02-26T10:11:05Z 905.92MB [restore_to_time: 2024-02-26T10:11:07Z] - 2024-02-26T10:06:57Z 86.99MB [restore_to_time: 2024-02-26T10:07:00Z] - 2024-02-26T10:03:24Z 234.12MB [restore_to_time: 2024-02-26T10:03:26Z] - 2024-02-26T10:00:16Z 910.27MB [restore_to_time: 2024-02-26T10:00:18Z] - 2024-02-26T08:43:44Z 86.83MB [restore_to_time: 2024-02-26T08:43:47Z] - PITR chunks [8.73MB]: - 2024-02-26T08:43:48Z - 2024-02-26T10:17:21Z - ``` + ??? example "Sample output" + + ```{.text .no-copy} + Backups: + Snapshots: + 2024-02-26T10:11:05Z 905.92MB [restore_to_time: 2024-02-26T10:11:07Z] + 2024-02-26T10:06:57Z 86.99MB [restore_to_time: 2024-02-26T10:07:00Z] + 2024-02-26T10:03:24Z 234.12MB [restore_to_time: 2024-02-26T10:03:26Z] + 2024-02-26T10:00:16Z 910.27MB [restore_to_time: 2024-02-26T10:00:18Z] + 2024-02-26T08:43:44Z 86.83MB [restore_to_time: 2024-02-26T08:43:47Z] + PITR chunks [8.73MB]: + 2024-02-26T08:43:48Z - 2024-02-26T10:17:21Z + ``` By default, the ``pbm delete-backup`` command asks for your confirmation to proceed with the deletion. To bypass it, add the `-y` or `--yes` flag. diff --git a/docs/usage/describe-backup.md b/docs/usage/describe-backup.md index 8b3d627d..1bef4924 100644 --- a/docs/usage/describe-backup.md +++ b/docs/usage/describe-backup.md @@ -8,7 +8,7 @@ $ pbm describe-backup The output provides the backup name, type, status, size and the information about the cluster topology it was taken in. For [selective backups](../features/selective-backup.md), it also shows the namespaces that were backed up. -??? example "Output" +??? example "Sample output" ```{.text .no-copy} name: "2022-08-17T10:49:03Z" @@ -41,7 +41,7 @@ To view the backup contents, use the `--with-collections` flag: $ pbm describe-backup --with-collections ``` -??? example "Output" +??? example "Sample output" ```{.text .no-copy} name: "2023-09-14T14:44:33Z" diff --git a/docs/usage/list-backup.md b/docs/usage/list-backup.md index 1b3d349e..fe4f492c 100644 --- a/docs/usage/list-backup.md +++ b/docs/usage/list-backup.md @@ -20,18 +20,18 @@ The output provides the following information: * The time to which the sharded cluster / non-shared replica set will be returned to after the restore. Available starting with version 1.4.0. * If [point-in-time recovery](../features/point-in-time-recovery.md) is enabled, its status and the valid time ranges for the restore -**Sample output** - -```{.text .no-copy} -Backup snapshots: - 2023-03-10T10:44:52Z [restore_to_time: 2023-03-10T10:44:56Z] - 2023-03-10T10:49:20Z [restore_to_time: 2023-03-10T10:49:23Z] - 2023-03-10T10:50:22Z [restore_to_time: 2023-03-10T10:50:25Z] - 2023-03-10T10:51:02Z [restore_to_time: 2023-03-10T10:51:04Z] - 2023-03-10T10:57:47Z [restore_to_time: 2023-03-10T10:57:49Z] - 2023-03-10T11:04:25Z [restore_to_time: 2023-03-10T11:04:27Z] - 2023-03-10T11:05:03Z [restore_to_time: 2023-03-10T11:05:07Z] -``` +??? example "Sample output" + + ```{.text .no-copy} + Backup snapshots: + 2023-03-10T10:44:52Z [restore_to_time: 2023-03-10T10:44:56Z] + 2023-03-10T10:49:20Z [restore_to_time: 2023-03-10T10:49:23Z] + 2023-03-10T10:50:22Z [restore_to_time: 2023-03-10T10:50:25Z] + 2023-03-10T10:51:02Z [restore_to_time: 2023-03-10T10:51:04Z] + 2023-03-10T10:57:47Z [restore_to_time: 2023-03-10T10:57:49Z] + 2023-03-10T11:04:25Z [restore_to_time: 2023-03-10T11:04:27Z] + 2023-03-10T11:05:03Z [restore_to_time: 2023-03-10T11:05:07Z] + ``` ## Restore to time diff --git a/docs/usage/pitr-tutorial.md b/docs/usage/pitr-tutorial.md index 4a5acaf8..ef8d0ee1 100644 --- a/docs/usage/pitr-tutorial.md +++ b/docs/usage/pitr-tutorial.md @@ -17,7 +17,7 @@ Run [`pbm status`](../reference/pbm-commands.md#pbm-status) or [`pbm list`](../r ## Procedure -=== "From logical backups" +=== ":material-data-matrix: From logical backups" Run [`pbm restore`](../reference/pbm-commands.md#pbm-restore) and specify the timestamp from the valid range: @@ -68,7 +68,7 @@ Run [`pbm status`](../reference/pbm-commands.md#pbm-status) or [`pbm list`](../r $ pbm config --set pitr.enabled=true ``` -=== "From physical backups" +=== ":material-database-refresh-outline: From physical backups" Starting with version [2.2.0](../release-notes/2.2.0.md), you can recover your database from a full or an incremental physical backup in the same automated fashion as from a logical one. Percona Backup for MongoDB restores the backup snapshot and automatically replays the oplog events on top of it up to the specified time, guaranteeing data consistency. This helps you prevent data loss during a disaster and gives you the same user experience when managing backups and restores. diff --git a/docs/usage/restore.md b/docs/usage/restore.md index 39e522c7..7b3a3128 100644 --- a/docs/usage/restore.md +++ b/docs/usage/restore.md @@ -4,7 +4,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re ## Considerations -=== "Logical" +=== ":material-data-matrix: Logical" 1. While the restore is running, prevent clients from accessing the database. The data will naturally be incomplete while the restore is in progress, and writes the clients make cause the final restored data to differ from the backed-up data. @@ -18,12 +18,12 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re 5. Starting with versions 1.x, Percona Backup for MongoDB replicates `mongodump’s` behavior to only drop collections in the backup. It does not drop collections that are created new after the time of the backup and before the restore. Run a `db.dropDatabase()` manually in all non-system databases (these are all databases except “local”, “config” and “admin”) before running `pbm restore` if you want to guarantee that the post-restore database only includes collections that are in the backup. -=== "Physical" +=== ":material-database-refresh-outline: Physical" 1. The Percona Server for MongoDB version for both backup and restore data must be within the same major release. 2. For PBM versions before 2.1.0, physical restores are not supported for deployments with arbiter nodes. -=== "Incremental" +=== ":simple-databricks: Incremental" 1. The Percona Server for MongoDB version for both backup and restore data must be within the same major release. 2. Incremental backups made with PBM before PBM 2.1.0 are incompatible for restore with PBM 2.1.0 and onwards. @@ -31,7 +31,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re ## Before you start -=== "Logical" +=== ":material-data-matrix: Logical" 1. Stop the balancer. @@ -39,23 +39,23 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re 3. For PBM version 2.3.1 and earlier, manually disable point-in-time recovery if it is enabled. To learn more about point-in-time recovery, see [Point-in-time recovery](../features/point-in-time-recovery.md). -=== "Physical" +=== ":material-database-refresh-outline: Physical" 1. Shut down all `mongos` nodes as the database won't be available while the restore is in progress. 2. Stop the arbiter nodes manually since there's no `pbm-agent` on these nodes to do that automatically. -=== "Selective" +=== ":material-select-multiple: Selective" You can restore a specific database or a collection either from a full or a selective backup. Read about [known limitations of selective restores](../features/selective-backup.md#known-limitations-of-selective-backups-and-restores). -=== "Incremental" +=== ":simple-databricks: Incremental" Before you start, shut down all `mongos` nodes as the database won’t be available while the restore is in progress. ## Restore a database -=== "Logical" +=== ":material-data-matrix: Logical" 1. List the backups to restore from @@ -140,7 +140,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re > db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } ) ``` -=== "Physical" +=== ":material-database-refresh-outline: Physical" 1. List the backups @@ -232,7 +232,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re * `downloadChunkMb` is the size of the data chunk to download (by default, 32 MB) -=== "Selective" +=== ":material-select-multiple: Selective" 1. List the backups @@ -247,7 +247,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re During the restore, Percona Backup for MongoDB retrieves the file for the specified database / collection and restores it. -=== "Incremental" +=== ":simple-databricks: Incremental" Restore flow from an incremental backup is the same as the restore from a full physical backup: specify the backup name for the `pbm restore` command: @@ -275,7 +275,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re 3. Start the balancer and the `mongos` node. 4. As the general recommendation, make a new base backup to renew the starting point for subsequent incremental backups. -=== "Snapshot-based" +=== ":material-database-export: Snapshot-based" See [snapshot-based backups](../features/snapshots.md#restore-a-backup). @@ -304,13 +304,13 @@ To restore data to the environment with different replica set names, configure t Configure the replica set name mapping: -=== "Using the environment variable for `pbm` CLI in your shell" +=== ":material-application-variable-outline: Using the environment variable for `pbm` CLI in your shell" ```{.bash data-prompt="$"} $ export PBM_REPLSET_REMAPPING="rsX=rsA,rsY=rsB" ``` -=== "Using the command line" +=== ":material-console: Using the command line" ```{.bash data-prompt="$"} $ pbm restore --replset-remapping="rsX=rsA,rsY=rsB" diff --git a/docs/usage/schedule-backup.md b/docs/usage/schedule-backup.md index 2a875854..a8952867 100644 --- a/docs/usage/schedule-backup.md +++ b/docs/usage/schedule-backup.md @@ -21,13 +21,13 @@ The steps are the following: 1. Create an environment file. Let’s name it `pbm-cron`. - === "Debian and Ubuntu" + === ":material-debian: Debian and Ubuntu" ```{.bash data-prompt="$"} $ vim /etc/default/pbm-cron ``` - === "Red Hat Enterprise Linux and derivatives" + === ":material-redhat: Red Hat Enterprise Linux and derivatives" ```{.bash data-prompt="$"} $ vim /etc/sysconfig/pbm-cron @@ -89,7 +89,7 @@ Starting with version 2.1.0, you can use the [`pbm cleanup --older-than`](../ref You can configure a `cron` task to automate storage cleanup by specifying the following command in the `crontab` file: ```{.bash data-prompt="$"} -$ $ /usr/bin/pbm cleanup -y --older-than 30d --wait +$ /usr/bin/pbm cleanup -y --older-than 30d --wait ``` This command deletes backups and oplog slices that are older than 30 days. You can change the period by specifying a desired interval for the `--older-than` flag. diff --git a/docs/usage/start-backup.md b/docs/usage/start-backup.md index 58246ed4..effbffea 100644 --- a/docs/usage/start-backup.md +++ b/docs/usage/start-backup.md @@ -7,7 +7,7 @@ ## Make a backup -=== "Logical" +=== ":material-data-matrix: Logical" To make a backup, run the following command: @@ -23,7 +23,7 @@ Multi-format is now the default data format since it allows [selective restore](restore.md). Note, however, that you can make only full restores from backups made with earlier versions of Percona Backup for MongoDB. -=== "Physical" +=== ":material-database-refresh-outline: Physical" !!! admonition "Version added: [1.7.0](../release-notes/1.7.0.md)" @@ -35,7 +35,7 @@ Starting with [2.4.0](../release-notes/2.4.0.md), PBM doesn't stop [point-in-time recovery oplog slicing](../features/point-in-time-recovery.md#oplog-slicing), if it's enabled, but runs it in parallel. This ensures [point-in-time recovery](pitr-tutorial.md) to any timestamp if it takes too long (e.g. hours) to make a backup snapshot. -=== "Selective" +=== ":material-select-multiple: Selective" !!! admonition "Version added: [2.0.0](../release-notes/2.0.0.md)" @@ -57,7 +57,7 @@ Multi-format is now the default data format for both full and selective backups since it allows selective restore. Note, however, that you can make only full restores from backups made with earlier versions of Percona Backup for MongoDB. -=== "Incremental" +=== ":simple-databricks: Incremental" !!! admonition "Version added: [2.0.3](../release-notes/2.0.3.md)" @@ -77,15 +77,17 @@ The incremental backup history looks like this: - ```{.bash .no-copy} - Snapshots: - 2022-11-25T14:13:43Z 139.82MB [restore_to_time: 2022-11-25T14:13:45Z] - 2022-11-25T14:02:07Z 255.20MB [restore_to_time: 2022-11-25T14:02:09Z] - 2022-11-25T14:00:22Z 228.30GB [restore_to_time: 2022-11-25T14:00:24Z] - 2022-11-24T14:45:53Z 220.13GB [restore_to_time: 2022-11-24T14:45:55Z] - ``` + ??? example "Sample output" + + ```{.bash .no-copy} + Snapshots: + 2022-11-25T14:13:43Z 139.82MB [restore_to_time: 2022-11-25T14:13:45Z] + 2022-11-25T14:02:07Z 255.20MB [restore_to_time: 2022-11-25T14:02:09Z] + 2022-11-25T14:00:22Z 228.30GB [restore_to_time: 2022-11-25T14:00:24Z] + 2022-11-24T14:45:53Z 220.13GB [restore_to_time: 2022-11-24T14:45:55Z] + ``` -=== "Snapshot-based" +=== ":material-database-export: Snapshot-based" See [snapshot-based backups](../features/snapshots.md#make-a-backup). @@ -185,8 +187,8 @@ This ability to adjust node priority helps you manage your backup strategy by se ## Next steps -* [List backups](../usage/list-backup.md) -* [Make a restore](restore.md) +[List backups](../usage/list-backup.md){.md-button} +[Make a restore](restore.md){.md-button} ## Useful links