From c5c08f5f3a0eba24da8232a82d753b1c75c293b9 Mon Sep 17 00:00:00 2001 From: Gary Gray Date: Wed, 24 Jun 2026 13:26:19 -0400 Subject: [PATCH 01/28] Initial in-progress commit. --- modules/ROOT/nav.adoc | 1 + .../partials/new-features-81.adoc | 9 ++ .../services/backup-service.adoc | 8 ++ .../services/continuous-backup.adoc | 96 +++++++++++++++++++ preview/DOC-12561_Continuous_backup_PITR.yml | 27 ++++++ 5 files changed, 141 insertions(+) create mode 100644 modules/learn/pages/services-and-indexes/services/continuous-backup.adoc create mode 100644 preview/DOC-12561_Continuous_backup_PITR.yml diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index e58f9a4279..ce2ab0eec8 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -61,6 +61,7 @@ include::third-party:partial$nav.adoc[] ** xref:learn:services-and-indexes/services/analytics-service.adoc[Analytics Service] ** xref:learn:services-and-indexes/services/eventing-service.adoc[Eventing Service] ** xref:learn:services-and-indexes/services/backup-service.adoc[Backup Service] + *** xref:learn:services-and-indexes/services/continuous-backup.adoc[Continuous Backup & PITR] * xref:learn:clusters-and-availability/clusters-and-availability.adoc[Clusters and Availability] ** xref:learn:clusters-and-availability/cluster-manager.adoc[Cluster Manager] ** xref:learn:clusters-and-availability/metadata-management.adoc[Metadata Management] diff --git a/modules/introduction/partials/new-features-81.adoc b/modules/introduction/partials/new-features-81.adoc index 58b3a29b1f..4b549fe7fd 100644 --- a/modules/introduction/partials/new-features-81.adoc +++ b/modules/introduction/partials/new-features-81.adoc @@ -61,3 +61,12 @@ TBD. Couchbase Server 8.1 introduces several new features for the xref:search:search.adoc[Search Service]. TBD. + +=== Backup Service + +Couchbase Server 8.1 introduces several new features for the xref:backup:backup.adoc[Backup Service]. + +* The new continuous backup feature supplements traditional periodic backups by frequently backing up changes to Magma buckets. +This backup can limit the loss of data updates that occur between full and incremental backups. +In addition to backup up data, it also backs up timestamps of when the data was updated. +These timestamps let you perform Point-In-Time Recovery (PITR) to restore the Magma bucket's data to the state it was in at a specific moment. diff --git a/modules/learn/pages/services-and-indexes/services/backup-service.adoc b/modules/learn/pages/services-and-indexes/services/backup-service.adoc index e24e3c1438..1f89e97778 100644 --- a/modules/learn/pages/services-and-indexes/services/backup-service.adoc +++ b/modules/learn/pages/services-and-indexes/services/backup-service.adoc @@ -36,6 +36,14 @@ To use it on a regular schedule, you must rely on an external scheduling system See xref:backup-restore:enterprise-backup-restore.adoc[cbbackupmgr] for more information about using the command-line tool. +== The Backup Service and Continuous Backup + +In addition to the periodic backups provided by the Backup Service, you can also use the continuous backup agent to frequently back up changes to Magma buckets. +This backup can limit the loss of data updates that occur between full and incremental backups. +It also records the timestamps of when data was mutated. +These timestamps let you perform Point-In-Time Recovery (PITR) to restore the Magma bucket's data to the state it was in at a specific moment. +See xref:learn:services/continuous-backup.adoc[] for more information about using continuous backup. + [#backup-service-architecture] == Backup Service Architecture diff --git a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc new file mode 100644 index 0000000000..841367e4cd --- /dev/null +++ b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc @@ -0,0 +1,96 @@ += Continuous Backup & Point in Time Recovery +:description: pass:q[Continuous backup frequently backs up mutations to Magma buckets and records timestamps to enable Point-In-Time Recovery (PITR).] +:enterprise-only: +:toclevels: 3 + +[abstract] +{description} + +The Backup Service and `cbbackupmgr` are designed to perform periodic backups. +For example, you may choose to have the Backup Service perform a daily full backup at midnight and then incremental backups every 2 hours. + +[ditaa] +.... + Periodic Backups + +----------+ +-----------+ + | cEEE | | cEEE | + | Full | |Incremental| + | Backup | | Backup | +Time ---+----------+-------------------------------------------------+-----------+------> + | | + Midnight 2:00 AM +.... + + +Any data mutations made since the last periodic backup could be lost if there is data loss or corruption. + +Continuous backup supplements full and incremental backups by performing backups at shorter intervals. +You can have it perform backups as frequently as every 2 minutes. +It can limit the loss of data mutations that take place between periodic full and incremental backups. +For example, the following diagram shows a continuous backup that's configured to perform backups every 10 minutes. + +[ditaa] +.... + Continuous Backups + +----------+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-----------+ + | cEEE | | | | | | | | | | | | | | | | | | | | | | | | | | cEEE | + | Full | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ |Incremental| + | Backup | | Backup | +--------+----------+-------------------------------------------------+-----------+------> + | | + | Midnight | 2:00 A.M. +.... + +== Point in Time Recovery + +With periodic backups, you can only restore a bucket to the state it was in when it was backed up. +For example, consider the backups shown in the Periodic Backup diagram. +You can only choose to restore the bucket to the state it was in at midnight or at 2 A.M. +You cannot restore it to any state between the 2 backups. + +In addition to backing up data, continuous backup also records the timestamp of data mutations. +These timestamps let you perform Point-In-Time Recovery (PITR)—restoring the bucket to the state it was in at a specific moment. + +Using PITR, you can precisely recover from data loss or corruption. +For example, suppose a user accidentally flushed a bucket. +You can restore the bucket to seconds before the flush occurred, recovering the lost data. + +== How Continuous Backup Works + +Continuous backup relies on feature of the Magma storage engine to track changes to the data in a bucket. +Because it relies on these features, continuous backup is only available for Magma buckets. +You cannot use it with Couchstore buckets. + +You enable continuous backup on a per-bucket basis. +This lets you choose to enable it for buckets that contain critical data, while leaving it off for buckets that do not need it. + +=== Continuous Backup Locations + +Continuous backup saves the data mutations and their timestamps to a backup storage location. +This location must be separate from the location of the backup repository for full and incremental backups. +All of the nodes in the cluster must have access to this storage location. +You can host the location on a shared network directory such as an NFS share. +Continuous backup also supports storage locations on Amazon S3, Microsoft Azure Blob Storage, and Google's Cloud Storage. + +=== Continuous Backup Interval + +When enabling continuous backup, you must choose the interval between continuous backup copy the mutations to a bucket's data to the backup location. +The minimum interval is 2 minutes. + + + + + +[ditaa] +.... + ++-------------+ +| Latest | Backup +| Continuous | Interval | Current +| Backup | +2 Minutes | Moment +| | <-----------> | +| cEEE | | ++-------------+ V +------------------------------*-----> + +.... \ No newline at end of file diff --git a/preview/DOC-12561_Continuous_backup_PITR.yml b/preview/DOC-12561_Continuous_backup_PITR.yml new file mode 100644 index 0000000000..bfbba5c0b2 --- /dev/null +++ b/preview/DOC-12561_Continuous_backup_PITR.yml @@ -0,0 +1,27 @@ +sources: + docs-devex: + branches: release/8.1 + +# docs-analytics: +# branches: release/8.0 + + couchbase-cli: + url: https://github.com/couchbaselabs/couchbase-cli-doc + branches: master + startPaths: docs/ + +# backup: +# branches: master +# startPaths: docs/ + + cb-swagger: + url: https://github.com/couchbaselabs/cb-swagger + branches: release/8.1 + start_path: docs + + # Minimal SDK build +# docs-sdk-common: +# branches: [release/8.0] +# docs-sdk-java: +# branches: [3.11] + From 1c4729137b24c1330079ac20e9645f097b7b5938 Mon Sep 17 00:00:00 2001 From: Gary Gray Date: Thu, 25 Jun 2026 16:26:09 -0400 Subject: [PATCH 02/28] Initial draft pf continuoud backup concepts page. Added note on change service page. --- modules/learn/pages/data/change-history.adoc | 5 + .../services/continuous-backup.adoc | 139 ++++++++++++++++-- 2 files changed, 130 insertions(+), 14 deletions(-) diff --git a/modules/learn/pages/data/change-history.adoc b/modules/learn/pages/data/change-history.adoc index dc7cac3def..003a3b423b 100644 --- a/modules/learn/pages/data/change-history.adoc +++ b/modules/learn/pages/data/change-history.adoc @@ -49,6 +49,11 @@ See xref:rest-api:rest-bucket-create.adoc[Creating and Editing Buckets]. * The CLI, using `couchbase-cli bucket-create` (to create a bucket) or `couchbase-cli bucket-edit` (to edit a bucket); specifying one or both of the parameters `history-retention-bytes` and `history-retention-seconds`. See xref:cli:cbcli/couchbase-cli-bucket-create.adoc[bucket-create] and xref:cli:cbcli/couchbase-cli-bucket-edit.adoc[bucket-edit]. +IMPORTANT: You must enable change history on any bucket you want to back up using continuous backup on. +Once you enable continuous backup, you cannot turn off change history for the bucket unless you turn off continuous backup first. +Using collection-level overrides of change history in a bucket where you have enabled continuous backup us unsupported. +See xref:learn:services/continuous-backup.adoc[] for more information. + [#default-collection-setting] === Default Collection-Setting diff --git a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc index 841367e4cd..23194e91ec 100644 --- a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc +++ b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc @@ -62,35 +62,146 @@ Because it relies on these features, continuous backup is only available for Mag You cannot use it with Couchstore buckets. You enable continuous backup on a per-bucket basis. -This lets you choose to enable it for buckets that contain critical data, while leaving it off for buckets that do not need it. +You can choose to enable it for buckets that contain critical data while leaving it off for buckets that not as vital or do not see many mutations. === Continuous Backup Locations Continuous backup saves the data mutations and their timestamps to a backup storage location. This location must be separate from the location of the backup repository for full and incremental backups. All of the nodes in the cluster must have access to this storage location. -You can host the location on a shared network directory such as an NFS share. +You can host the location on a shared network directory such as a Network File System (NFS) share. Continuous backup also supports storage locations on Amazon S3, Microsoft Azure Blob Storage, and Google's Cloud Storage. -=== Continuous Backup Interval +=== The Continuous Backup Interval -When enabling continuous backup, you must choose the interval between continuous backup copy the mutations to a bucket's data to the backup location. -The minimum interval is 2 minutes. +When enabling continuous backup, you must choose the interval when continuous backup copies the mutations to a bucket's data to the backup location. +The minimum interval is 2 minutes. +When setting the interval, you must consider potential data loss vs. potential increased storage cost. +The longer you make the interval, the greater the possibility of losing data mutations that occur before the next continuous backup. +It also affects the latest moment you can choose to restore the bucket to during a PITR. +[ditaa] +.... ++-------------+ Up to the +| Latest | backup +| continuous | interval | Current +| backup | + 2 Minutes | time +| | <-----------> | +| cEEE | | ++-------------+ V +--------------*---------------*---------> + | + Latest point in time + you can restore to +.... + +The latest point in time you can restore the bucket to is within the latest continuous backup. +This can be as long as the entire backup interval, plus an additional 2 minutes. +The additional 2 minutes is because Magma flushes its in-memory data to disk every 2 minutes. + +The continuous backup interval plus 2 minutes is the worst case scenario. +In most cases, you'll be able to restore to a more recent point in time. + +A shorter continuous backup interval can cost you more money if your storage location is cloud-based. +The cloud services that continuous backup supports all have per-request fees in addition to their raw data storage fee. +Having a shorter interval means more frequent API requests, and therefore more charges. +A continuous backup interval of 5 minutes costs you twice the amount of request fees than a 10 minute backup interval. +The continuous backup interval setting is per bucket. +You can choose to have a shorter continuous backup interval on vital buckets that have a higher volume mutations. +You can also set a longer interval for less important buckets have fewer mutations. +=== Continuous Backup Retention + +Continuous backup retains its backups for a configurable period of time. +The range you can set the retention period is from 1 hour to 60 days. + +The retention period controls how far back in time you can restore a bucket using PITR. +Continuous backup purges data that's older than the retention period. +Once continuous backup purges the data, you cannot perform a PITR to the range of time it contained. + +Assuming you have traditional full and incremental backups older than the continuous backup retention period, you can use them to restore the bucket. +However, they can only restore the bucket to the state it was in when the backup was taken. +You cannot use them to restore the bucket to an arbitrary point in time. + +When choosing the retention period, you must balance between the cost of storing the backup data and the flexibility of restoring your bucket to an earlier time. +If you choose cloud storage for your continuous backup location, you pay data storage fees based on the amounrt of data you store. +These fees increase the longer you set the retention period. + +== How PITR Works + +You can perform a PITR on a bucket to the same cluster or a different cluster. +When restoring to the same cluster, you can choose to restore to the a new bucket or to the existing bucket. + +If you're restoring to the original bucket, decide whether you want the bucket to be in the state it was in at the specific point in time. +PITR does not automatically flush the bucket before performing a restore. +Any documents added after the point in time you choose will remain in the bucket. +However, mutations to existing documents made after the point in time are lost. +If you want the bucket to be the way it was at the point in time you chose to restore to, flush the bucket before restoring. + +When perform a PITR on a bucket, continuous backup first restores the most recent full and incremental backups from before restore time you chose. +It then replays the mutations stored in the continuous backups in order until it reaches the restore time you chose. [ditaa] .... + + +----------+ +-----------+ + | cEEE | | cEEE | Continuous Backups + | Full | |Incremental| +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ + | Backup | | Backup | | | | | | | | | | | | | | | | | | | +--------+----------*---------+-----------+--+-+-+-+-+-+-+-+-+-+-+-+-+-*-+-+-+-+--------> + | | | | + Restored Restored |<----------------------->| + first second Continuous backups | + replayed | + Selected + point in + time +.... -+-------------+ -| Latest | Backup -| Continuous | Interval | Current -| Backup | +2 Minutes | Moment -| | <-----------> | -| cEEE | | -+-------------+ V -------------------------------*-----> -.... \ No newline at end of file +== Continuous Backup's Impact on the Cluster + +Enabling has several impacts on the cluster and interactions with other features. + +=== Disk Use + +Continuous backup increases the disk usage on nodes. +Couchbase Server has to retain some files it would otherwise delete until continuous backup can back them up. +The amount of added disk space depends on the number of mutations and the length of the continuous backup interval. + +=== Change History Requirement + +As part of enabling continuous backup, you must enable the bucket's change history. +Change history is a Magma feature that lets continuous backup record the mutations so it can replay them back during a PITR. +When you have continuous backup enabled for a bucket, you cannot turn off the bucket's change history setting. + +When you enable continuous backup for a bucket, disabling change history for individual collections is not supported. +Verify that no collection has a change history override setting on it before enabling continuous backup. + +See xref:learn/:data/change-history.adoc[] for more information about change history. + +=== Continuous Backup and Unsafe Failover + +For continuous backup to be able to reliably restore a bucket to a point it time, it must have a consistent history of the changes made to a bucket. +An xref:learn:clusters-and-availability/hard-failover.adoc#performing-an-unsafe-failover[unsafe failover] can cause consistency issues in this history. +If you must perform an unsafe failover on a node, first stop the Couchbase Server process on it. +Stopping the process prevents inconsistencies in history, and protects continuous backup's ability to perform a PITR. + +See xref:install:startup-shutdown.adoc[] for more instructions on shutting down the Couchbase Server process. + +=== Continuous Backup and Encryption at Rest + +When you enable encryption at rest for a bucket's data, continuous backup needs to maintain a copy of the encryption at rest Data Encryption Keys (DEKs). +It needs its own copy of these keys because the encryption at rest feature rotates its DEKs. +Therefore, the current DEKs are usually not the same ones continuous backup needs to decrypt older the data in its backups. +Continuous backup creates a backup of the DEKs along with the bucket's data. + +Continuous backup must have access to a Key Management System (KMS) to protect the DEKs it saves alongside the bucket data. +It uses the KMS to securely re-encrypt the DEKs. +This re-encryption protects the keys the same way encryption at rest does. +All nodes in the cluster must be able to connect to the KMS you configure for continuous backup. + +If you have already configured a KMS to manage encryption keys for your traditional full and incremental backups, you can reuse it to manage the keys for continuous backup. + From d743b51963679cee318ff4820a09bee9f88afcc7 Mon Sep 17 00:00:00 2001 From: Gary Gray Date: Mon, 29 Jun 2026 16:56:25 -0400 Subject: [PATCH 03/28] Draft of the manage continuous backup page. --- modules/ROOT/nav.adoc | 1 + .../hard-failover.adoc | 4 + .../services/continuous-backup.adoc | 65 ++-- .../manage-continuous-backup.adoc | 300 ++++++++++++++++++ 4 files changed, 345 insertions(+), 25 deletions(-) create mode 100644 modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index ce2ab0eec8..720981dcd4 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -186,6 +186,7 @@ include::third-party:partial$nav.adoc[] *** xref:backup-restore:cbbackupmgr-cloud.adoc[Cloud Backup] *** xref:backup-restore:cbbackupmgr-network-filesystems.adoc[Network Filesystems] *** xref:backup-restore:cbbackupmgr-encryption.adoc[Encryption] + ** xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc[] * xref:manage:monitor/monitor-intro.adoc[Monitor] ** xref:manage:monitor/xdcr-monitor-timestamp-conflict-resolution.adoc[Monitor Clock Drift] ** xref:manage:monitor/set-up-prometheus-for-monitoring.adoc[] diff --git a/modules/learn/pages/clusters-and-availability/hard-failover.adoc b/modules/learn/pages/clusters-and-availability/hard-failover.adoc index 5eb0732f62..d1d9c132e4 100644 --- a/modules/learn/pages/clusters-and-availability/hard-failover.adoc +++ b/modules/learn/pages/clusters-and-availability/hard-failover.adoc @@ -39,6 +39,10 @@ Note that this restriction also protects the cluster in situations where multipl [#performing-an-unsafe-failover] === Performing an Unsafe Failover +CAUTION: If you have 1 or more buckets using continuous backup, you must stop the Couchbase Server process on the node before performing an unsafe failover on it. +Not stopping the Couchbase Server process could result in data inconsistencies that can cause issues with the continuous backup. +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for more information. + In Couchbase Server 7.0 or a later version, metadata is managed by a _consensus protocol_; which achieves strong consistency by _synchronously_ replicating metadata to a majority of the nodes before considering it committed. (This is described in xref:learn:clusters-and-availability/metadata-management.adoc[Metadata Management].) The metadata so managed includes _topology information_. diff --git a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc index 23194e91ec..5e496207c8 100644 --- a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc +++ b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc @@ -72,6 +72,15 @@ All of the nodes in the cluster must have access to this storage location. You can host the location on a shared network directory such as a Network File System (NFS) share. Continuous backup also supports storage locations on Amazon S3, Microsoft Azure Blob Storage, and Google's Cloud Storage. +You can use 1 continuous backup storage location to store backups for multiple buckets. +Having multiple buckets sharing the same storage location makes performing PITR on multiple buckets easier. +You use the same commands to restore multiple buckets. + +You can also use different storage locations for buckets. +Separate locations are useful in multi-tenancy configurations. +Each tenant can supply their own continuous backup location. +You can also separately track the cost of a tenant's cloud-based continuous backup location. + === The Continuous Backup Interval When enabling continuous backup, you must choose the interval when continuous backup copies the mutations to a bucket's data to the backup location. @@ -140,47 +149,53 @@ Any documents added after the point in time you choose will remain in the bucket However, mutations to existing documents made after the point in time are lost. If you want the bucket to be the way it was at the point in time you chose to restore to, flush the bucket before restoring. -When perform a PITR on a bucket, continuous backup first restores the most recent full and incremental backups from before restore time you chose. -It then replays the mutations stored in the continuous backups in order until it reaches the restore time you chose. +When restoring, PITR first restores the latest full and incremental backups from before restore time you chose. +It then replays the mutations stored in the continuous backups since the last full or incremental backup. +It continues replaying the mutations until it reaches the point in time you chose. [ditaa] .... - +----------+ +-----------+ - | cEEE | | cEEE | Continuous Backups - | Full | |Incremental| +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ - | Backup | | Backup | | | | | | | | | | | | | | | | | | | ---------+----------*---------+-----------+--+-+-+-+-+-+-+-+-+-+-+-+-+-*-+-+-+-+--------> - | | | | - Restored Restored |<----------------------->| - first second Continuous backups | - replayed | - Selected - point in - time + +----------+ +-----------+ + | cEEE | | cEEE | Continuous Backups + | Full | . . . |Incremental+--+--+--+--+--+--+--+--+--+ + | Backup | | Backup | | | | | | | | | | +----+----------+---------+-----------+--+--+--+--+--+--+--+*-+--+--> + | | | | + Restored Restored |<------------------->| + first second Continuous backups | + replayed | + | + Selected + point in + time .... -== Continuous Backup's Impact on the Cluster +== Continuous Backup's Effects on the Cluster Enabling has several impacts on the cluster and interactions with other features. -=== Disk Use - -Continuous backup increases the disk usage on nodes. +* Continuous backup increases the disk usage on nodes. Couchbase Server has to retain some files it would otherwise delete until continuous backup can back them up. The amount of added disk space depends on the number of mutations and the length of the continuous backup interval. -=== Change History Requirement +* You must use the credential store to provide the credentials for any cloud storage locations you use for continuous backup. +The credential store has its own requirements---you must enable peer-to-peer encryption and encryption at rest for Couchbase Server configuration files. +See the credential store documentation for more information. + +// FIXME: add link to the credential store docs when they are done. -As part of enabling continuous backup, you must enable the bucket's change history. +* As part of enabling continuous backup, you must enable the bucket's change history. Change history is a Magma feature that lets continuous backup record the mutations so it can replay them back during a PITR. When you have continuous backup enabled for a bucket, you cannot turn off the bucket's change history setting. ++ When you enable continuous backup for a bucket, disabling change history for individual collections is not supported. Verify that no collection has a change history override setting on it before enabling continuous backup. -See xref:learn/:data/change-history.adoc[] for more information about change history. ++ +See xref:learn:data/change-history.adoc[] for more information about change history. === Continuous Backup and Unsafe Failover @@ -193,12 +208,12 @@ See xref:install:startup-shutdown.adoc[] for more instructions on shutting down === Continuous Backup and Encryption at Rest -When you enable encryption at rest for a bucket's data, continuous backup needs to maintain a copy of the encryption at rest Data Encryption Keys (DEKs). -It needs its own copy of these keys because the encryption at rest feature rotates its DEKs. +If you enable encryption at rest for a bucket's data, continuous backup needs to maintain a copy of the encryption at rest Data Encryption Keys (DEKs). +It needs its own copy of these keys because the encryption at rest rotates its DEKs. Therefore, the current DEKs are usually not the same ones continuous backup needs to decrypt older the data in its backups. -Continuous backup creates a backup of the DEKs along with the bucket's data. +Continuous backup creates a backup of the DEKs along with the bucket's data so that it can decrypt the data itself. -Continuous backup must have access to a Key Management System (KMS) to protect the DEKs it saves alongside the bucket data. +To protect the DEKs, you must configure continuous backup with access to a Key Management System (KMS) to protect the DEKs it saves alongside the bucket data. It uses the KMS to securely re-encrypt the DEKs. This re-encryption protects the keys the same way encryption at rest does. All nodes in the cluster must be able to connect to the KMS you configure for continuous backup. diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc new file mode 100644 index 0000000000..6768c26415 --- /dev/null +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -0,0 +1,300 @@ += Manage Continuous Backup +:description: pass:q[This topic describes how to configure continuous backup to frequently back up the data in your Magma buckets.] +:enterprise-only: +:toclevels: 3 + +[abstract] +{description} +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an overview of continuous backup. + +== Prerequisites + +Before configuring continuous backup, your cluster must meet the following requirements: + +* It must have 1 or more Magma buckets. +Continuous backup relies on Magma's change history feature to back up individual mutations. +You cannot use it on Couchstore buckets. +Couchstore buckets can still be backed up and restored using the traditional full and incremental backups. + +* Verify that all of the system clocks in your cluster are synchronized. +See xref:install:synchronize-clocks-using-ntp.adoc[] for more information. + +* You must configure scheduled periodic backups using either the Backup Service or `cbbackupmgr`. +Point in Time Recovery (PITR) uses the full and incremental backups taken just before the point in time you're restoring to. +It restores these backups and then uses the data stored in the continuous backup to fill the gap between the previous intermittent backup and the point in time you're recovering to. +See xref:manage-backup-and-restore.adoc[] to learn how to configure intermittent backups. + +* You must have a shared location where continuous backup can store its backup data. +All node in the cluster must be able to reach this location. +It can be a shared filesystem, such as an NFS share. +You can also use cloud-based storage hosted by Amazon S3, Microsoft Azure Blob Storage, and Google's Cloud Storage. + ++ +Whatever location you choose, it must be empty of existing files and dedicated to continuous backup. +You can use the same storage location to store continuous backups for multiple buckets. +Using the same location makes performing a PITR on multiple buckets easier, as you can use the same commands to restore multiple buckets. + +* If you're using cloud-based storage for your continuous backup location, you must add the credentials to access the location to the Couchbase Server credential store. +You must also grant the backup service access to this credential. +See Credential Store for more information. + +// FIXME: add link to credential store docs once written. + +* If you have enabled encryption at rest for the bucket's data that you're backing up, you must supply continuous backup with access to a https://en.wikipedia.org/wiki/Key_management#Key_management_system[Key Management System^] (KMS). +It uses the KMS to encrypt the encryption at rest Data Access Keys (DEKs) it needs to decrypt the data during PITR. +If you have configured a KMS to encrypt keys for traditional periodic backup, you can reuse those credentials for continuous backup. +See xref:learn:security/native-encryption-at-rest-overview.adoc[] for more information about encryption at rest. + +== Configure Bucket Change History for Continuous Backup + +The continuous backup feature relies on the bucket having change history enabled. +Therefore, before you enable continuous backup, you must verify that the bucket's `historyRetentionCollectionDefault` setting is `true`. +You also must verify that no collection overrides the bucket's change history setting. + +You must also configure the bucket so that it keeps its change history long enough for continuous backup to save it to the storage location. + +See xref:learn:data/scopes-and-collections.adoc#change-history[Change History] for more information about the change history. + +To configure the bucket's change history settings: + +. Verify that the bucket's change history setting is the default value of `true`. +The following example calls the REST-API and pipes the result through `jq` to get the setting for the `travel-sample` bucket: + ++ +[source,bash] +``` +curl -s -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + http://node1.example.com:8091/pools/default/buckets/travel-sample \ + | jq '.historyRetentionCollectionDefault' +``` + ++ +The previous examples returns either `true` or `false`. + +. If the value is not `true`, set it to `true`. +The following example sets the `travel-sample` bucket to `true`. + ++ +[source,bash] +``` +curl -s POST -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + http://node1.example.com:8091/pools/default/buckets/travel-sample\ + -d historyRetentionCollectionDefault=true +``` + ++ +Then repeat step 1 to verify that `historyRetentionCollectionDefault` is now set to `true`. + +. Verify that no collection in the bucket overrides the bucket's `historyRetentionCollectionDefault` setting. +If a collection overrides this setting, continuous backup cannot back it up. +Excluding collections from continuous backup is unsupported. + ++ +The following example gets the settings for the `travel-sample` bucket and uses `jq` to locate aany collections that have their `history` key set to `false`: + ++ +[source,bash] +``` +$ curl -s GET -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + http://node1.example.com:8091/pools/default/buckets/travel-sample/scopes \ + | jq '.scopes[] + | select(.name != "_system") + | .name as $scope + | .collections[] + | select(.history == false) + | {scope: $scope, collection: .name, history: .history}' +``` + ++ +Any collections that have overrides appear in the output: + ++ +[source,json] +``` +{ + "scope": "inventory", + "collection": "airline", + "history": false +} +{ + "scope": "tenant_agent_01", + "collection": "bookings", + "history": false +} +``` + +. If any collections have overrides, edit them to change their `history` setting back to `true`. +The following example sets the history setting for the `airline` collection in the `inventory` scope to `true`. + ++ +[source,bash] +``` +curl -s -X PATCH -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + http://node1.example.com:8091/pools/default/buckets/travel-sample/scopes/inventory/collections/airline \ + -d history=true +``` + ++ +After editing the collections that had overrides, re-run step 3 to verify that no collection overrides the bucket's setting. + +. You must set the history retention time for the bucket to a period long enough for continuous backup to collect and save the bucket's history to the backup location. +This period is 15 minutes or double the continuous backup interval, whichever is longer. +For example, if you chose 10 minutes for your backup interval, you must set the retention time to 20 minutes. + ++ +The following example sets the `travel-sample` bucket's history retention to 20 minutes (1200 seconds). + ++ +[source,bash] +``` +curl -v -s POST -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + http://node1.example.com:8091/pools/default/buckets/travel-sample \ + -d historyRetentionSeconds=1200 +``` + + +== Configure Continuous Backup + +You can configure continuous backup using the Couchbase Server Web Console, the command line interface, or the REST API. + + + +=== Configure Continuous Backup Using the Web Console + +. Click *Buckets*. +. If creating a new bucket, click *Add Bucket*. +Otherwise, expand an existing bucket and click *Edit*. +. Click *Advanced Bucket Settings*. +. Under +. Under Continuous Backup, select *Enable*. +. Enter the location to store the continuous backup data. + This is either: + * An absolute path to the mount point of a shared network storage location such as an NFS share. + This mount point must be the same on all nodes. + * The cloud storage URI for the storage location. +. Set how frequently continuous backup saves data to the storage location in minutes. +Remember that if you use a cloud storage location, a lower settings for this value can often result in greater cost due to per-access charges. +The minimum value is 2. +. Set the number of hours Couchbase Server should retain the continuous backup data, +This value controls the window where you can restore to a point in time. +If you use the cloud as a backup storage location, a higher setting results in higher data storage charges. +. If you entered a cloud storage URI for the Backup Location, choose the credential from the credential store for the Backup Service to use when authenticating with the cloud provider. +Make sure you have granted access to Backup Service for this credential. +. If you have enabled encryption at rest for the data in the bucket, enter the URI for the KMS Key. +Valid URIs start with `awskms`, `azurekeyvalue`, or `gcpkms`. + +=== Configure Continuous Backup Using the REST API + +You can enable continuous backup when creating a bucket or editing it via the REST-API. + +Whether you're creating a new bucket or editing an existing bucket, make a POST call to the `/pools/default/buckets/` REST API endpoint. +Set the following : + + +* `continuousBackupEnabled`: set to `true` to enable continuous backup for the bucket. +* `continuousBackupLocation`: The location where the backup service will store the continuous backup data. +This value must be either an absolute path to NFS an mount point mounted on every node or a cloud storage URI. +* `continuousBackupCloudStorageCredId`: If you set `continuousBackupLocation` to a cloud storage URI, set this to the name of a credential in the credential store that the Backup Service can use to authenticate. +You must grant the Backup Service access to this credential. +* `continuousBackupInterval`: How frequently, in minutes, the Backup Service copies data to the continuous backup location. +When using a cloud-based storage location, lower settings for this value result in higher per-access costs. +* `continuousBackupRetentionPeriod`: the number of hours the Backup Service keeps the continuous backup data before purging it. +This value sets how far back in time you can use Point in Time Recovery (PITR). +* If you have enabled encryption at rest for the bucket, you must supply one of the following: +** `continuousBackupKmKeyUrl`: The URI for the KMS key the Backup Service uses to manage the encryption key it uses to encrypt data encryption keys. + This URI must start with `awskms`, `azurekeyvalue`, or `gcpkms`. +** `continuousBackupKmCredId`: the name of a credential in the Couchbase Server credential store that grants the Backup Service access to a KMS to manage its encryption keys. + +See xref:rest-api:rest-bucket-create.adoc[] for details of using the REST API to add and edit buckets. + +The following example enables continuous backup for `travel-sample` bucket. +It sets the backup interval to 10 minutes. +The backup location is an NFS share mounted on each not at the path `/shared.continuous-backup`. + +[source,bash] +``` +curl -X POST localhost:8091/pools/default/buckets/travel-sample \ + -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + -d continuousBackupEnabled=true \ + -d continuousBackupLocation="/shared/continuous-backup" \ + -d continuousBackupInterval=10 +``` + +=== Enable Continuous Backup Using the Command Line + +Use the `couchbase-cli` tool's `bucket create` or `bucket-edit` tool to change the continuous backup settings for the bucket. + +Use the following arguments to enable the continuous backup settings: + +* `--continuous-backup-enabled`: set to `1` to enable continuous backup for the bucket. +* `--continuous-backup-location`: The location where the backup service will store the continuous backup data. +This value must a string containing either an absolute path to NFS an mount point mounted on every node or a cloud storage URI. +* `--continuous-backup-cloud-storage-cred-id`: If you set `--continuous-backup-location` to a cloud storage URI, set this to the name of a credential in the Couchbase Server credential store that the Backup Service can use to authenticate. +You must grant the Backup Service access to this credential. +* `--continuous-backup-interval`: How frequently, in minutes, the Backup Service copies data to the continuous backup location. +When using a cloud-based storage location, lower settings for this value result in higher per-access costs. +* `--continuous-backup-retention-period`: the number of hours the Backup Service keeps the continuous backup data before purging it. +This value sets how far back in time you can use Point in Time Recovery (PITR). +* If you have enabled encryption at rest for the bucket, you must supply one of the following: +** `--continuous-backup-km-key-url`: The URI for the KMS key the Backup Service uses to manage the encryption key it uses to encrypt data encryption keys. + This URI must start with `awskms`, `azurekeyvalue`, or `gcpkms`. +** `--continuous-backup-km-cred=id`: the name of a credential in the Couchbase Server credential store that grants the Backup Service access to a KMS to manage its encryption keys. + + +The following example enables continuous backup on the `travel-sample` bucket. +It sets the backup interval to 10 minutes and the retention period to 30 days (270 hours). +The backup location is an NFS share mounted at `/shared/continuous-backup` on all nodes. + +[source,bash] +``` +couchbase-cli bucket-edit --cluster couchbase://node1.example.com \ + --username Administrator --password password \ + --bucket travel-sample \ + --continuous-backup-enabled 1 \ + --continuous-backup-location /shared/continuous-backup \ + --continuous-backup-interval 10 \ + --continuous-backup-retention-period 270 +``` + +## Turning Off Continuous Backup + +Once enabled, you can turn off continuous backup for a bucket. +You can turn off continuous backups before you do a PITR to prevent a backup from occurring during the restore. +You may also want to turn it off to prevent a point in time you may want to restore to from falling outside the retention window. + +You can turn off continuous backup using the Couchbase Server Web Console, REST API, or command line: + +Using the Couchbase Server Web Console:: + ++ +. Click *Buckets*. +. Click the entry for the bucket. +. Click *Edit*. +. Click *Advanced bucket settings*. +. Under *Continuous Backup*, deselect *Enabled*. +. Click *Save Changes*. + +Using the REST API:: + +Make a POST call to the `/pools/default/buckets/` endpoint and set to `false`. +For example, to turn off continuous backup for the `travel-sample` bucket, use this command: + ++ +[souce,bash] +``` +curl -X POST localhost:8091/pools/default/buckets/travel-sample \ + -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + -d continuousBackupEnabled=false +``` + +Using the Ccommand Line Interface:: + +Use the `couchbase-cli` tools' `edit-bucket` command with the argument `--continuous-backup-enabled 0`: + +[source.bash] +``` +couchbase-cli bucket-edit --cluster couchbase://node1.example.com \ + --username Administrator --password password \ + --bucket travel-sample \ + --continuous-backup-enabled 0 +``` From 44e4906b713c43aaa1d0242823cb6d38183c10d4 Mon Sep 17 00:00:00 2001 From: Gary Gray Date: Tue, 30 Jun 2026 16:43:39 -0400 Subject: [PATCH 04/28] * In progress on managing PITR. * Added minitor continuous backup. * Updated metrics. * Finished draft of manage continuous backup. --- modules/ROOT/nav.adoc | 2 + .../manage-continuous-backup.adoc | 76 ++++---- .../manage-pitr.adoc | 74 ++++++++ .../monitor-continuous-backup.adoc | 74 ++++++++ .../attachments/cm_metrics_metadata.json | 12 ++ .../attachments/fts_metrics_metadata.json | 10 + .../attachments/goxdcr_metrics_metadata.json | 10 +- .../attachments/index_metrics_metadata.json | 20 ++ .../attachments/kv_metrics_metadata.json | 173 ++++++++++++++++-- .../attachments/n1ql_metrics_metadata.json | 27 ++- preview/DOC-12561_Continuous_backup_PITR.yml | 6 +- 11 files changed, 421 insertions(+), 63 deletions(-) create mode 100644 modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc create mode 100644 modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 720981dcd4..7edf06da92 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -187,6 +187,8 @@ include::third-party:partial$nav.adoc[] *** xref:backup-restore:cbbackupmgr-network-filesystems.adoc[Network Filesystems] *** xref:backup-restore:cbbackupmgr-encryption.adoc[Encryption] ** xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc[] + ** xref:manage:manage-backup-and-restore/monitor-continuous-backup.adoc[] + ** xref:manage:manage-backup-and-restore/manage-pitr.adoc[] * xref:manage:monitor/monitor-intro.adoc[Monitor] ** xref:manage:monitor/xdcr-monitor-timestamp-conflict-resolution.adoc[Monitor Clock Drift] ** xref:manage:monitor/set-up-prometheus-for-monitoring.adoc[] diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index 6768c26415..940169c1ce 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -11,6 +11,8 @@ See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an ove Before configuring continuous backup, your cluster must meet the following requirements: +* Your Couchbase Server account must have the xref:learn:security/roles.adoc#backup-full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. + * It must have 1 or more Magma buckets. Continuous backup relies on Magma's change history feature to back up individual mutations. You cannot use it on Couchstore buckets. @@ -52,13 +54,14 @@ Therefore, before you enable continuous backup, you must verify that the bucket' You also must verify that no collection overrides the bucket's change history setting. You must also configure the bucket so that it keeps its change history long enough for continuous backup to save it to the storage location. +This period is either 15 minutes or twice the continuous backup interval, whichever is greater. -See xref:learn:data/scopes-and-collections.adoc#change-history[Change History] for more information about the change history. +See xref:learn:data/scopes-and-collections.adoc#change-history[Change History] for more information about Magma's change history feature. To configure the bucket's change history settings: . Verify that the bucket's change history setting is the default value of `true`. -The following example calls the REST-API and pipes the result through `jq` to get the setting for the `travel-sample` bucket: +The following example calls the REST API and pipes the result through `jq` to get the setting for the `travel-sample` bucket: + [source,bash] @@ -71,8 +74,7 @@ curl -s -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + The previous examples returns either `true` or `false`. -. If the value is not `true`, set it to `true`. -The following example sets the `travel-sample` bucket to `true`. +. If the value is not `true`, set it to `true` as shown in the following example: + [source,bash] @@ -83,30 +85,31 @@ curl -s POST -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ ``` + -Then repeat step 1 to verify that `historyRetentionCollectionDefault` is now set to `true`. +Repeat step 1 to verify that `historyRetentionCollectionDefault` is now set to `true`. . Verify that no collection in the bucket overrides the bucket's `historyRetentionCollectionDefault` setting. If a collection overrides this setting, continuous backup cannot back it up. Excluding collections from continuous backup is unsupported. + -The following example gets the settings for the `travel-sample` bucket and uses `jq` to locate aany collections that have their `history` key set to `false`: +The following example gets the settings for the `travel-sample` bucket and uses `jq` to locate any collections that have their `history` key set to `false`: + [source,bash] ``` -$ curl -s GET -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ - http://node1.example.com:8091/pools/default/buckets/travel-sample/scopes \ - | jq '.scopes[] - | select(.name != "_system") - | .name as $scope - | .collections[] - | select(.history == false) - | {scope: $scope, collection: .name, history: .history}' +curl -s GET -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ + http://node1.example.com:8091/pools/default/buckets/travel-sample/scopes \ + | jq '.scopes[] + | select(.name != "_system") + | .name as $scope + | .collections[] + | select(.history == false) + | {scope: $scope, collection: .name, history: .history}' ``` + -Any collections that have overrides appear in the output: +Any collections that have overrides appear in the output. +For example: + [source,json] @@ -123,7 +126,7 @@ Any collections that have overrides appear in the output: } ``` -. If any collections have overrides, edit them to change their `history` setting back to `true`. +. If any collections have overrides, edit them to change their `history` setting to `true`. The following example sets the history setting for the `airline` collection in the `inventory` scope to `true`. + @@ -139,7 +142,7 @@ After editing the collections that had overrides, re-run step 3 to verify that n . You must set the history retention time for the bucket to a period long enough for continuous backup to collect and save the bucket's history to the backup location. This period is 15 minutes or double the continuous backup interval, whichever is longer. -For example, if you chose 10 minutes for your backup interval, you must set the retention time to 20 minutes. +For example, if you chose 10 minutes for your continuous backup interval, set the retention time to 20 minutes. + The following example sets the `travel-sample` bucket's history retention to 20 minutes (1200 seconds). @@ -147,7 +150,7 @@ The following example sets the `travel-sample` bucket's history retention to 20 + [source,bash] ``` -curl -v -s POST -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ +curl -s POST -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ http://node1.example.com:8091/pools/default/buckets/travel-sample \ -d historyRetentionSeconds=1200 ``` @@ -157,8 +160,6 @@ curl -v -s POST -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ You can configure continuous backup using the Couchbase Server Web Console, the command line interface, or the REST API. - - === Configure Continuous Backup Using the Web Console . Click *Buckets*. @@ -188,7 +189,7 @@ Valid URIs start with `awskms`, `azurekeyvalue`, or `gcpkms`. You can enable continuous backup when creating a bucket or editing it via the REST-API. Whether you're creating a new bucket or editing an existing bucket, make a POST call to the `/pools/default/buckets/` REST API endpoint. -Set the following : +Set the following: * `continuousBackupEnabled`: set to `true` to enable continuous backup for the bucket. @@ -204,9 +205,7 @@ This value sets how far back in time you can use Point in Time Recovery (PITR). ** `continuousBackupKmKeyUrl`: The URI for the KMS key the Backup Service uses to manage the encryption key it uses to encrypt data encryption keys. This URI must start with `awskms`, `azurekeyvalue`, or `gcpkms`. ** `continuousBackupKmCredId`: the name of a credential in the Couchbase Server credential store that grants the Backup Service access to a KMS to manage its encryption keys. - -See xref:rest-api:rest-bucket-create.adoc[] for details of using the REST API to add and edit buckets. - + The following example enables continuous backup for `travel-sample` bucket. It sets the backup interval to 10 minutes. The backup location is an NFS share mounted on each not at the path `/shared.continuous-backup`. @@ -220,18 +219,21 @@ curl -X POST localhost:8091/pools/default/buckets/travel-sample \ -d continuousBackupInterval=10 ``` +See xref:rest-api:rest-bucket-create.adoc[] for details about editing bucket settings using the REST API. + === Enable Continuous Backup Using the Command Line -Use the `couchbase-cli` tool's `bucket create` or `bucket-edit` tool to change the continuous backup settings for the bucket. +Use the `couchbase-cli` tool's `bucket create` or `bucket-edit` command to change the continuous backup settings for the bucket. -Use the following arguments to enable the continuous backup settings: +Use the following arguments to configure continuous backup: * `--continuous-backup-enabled`: set to `1` to enable continuous backup for the bucket. * `--continuous-backup-location`: The location where the backup service will store the continuous backup data. -This value must a string containing either an absolute path to NFS an mount point mounted on every node or a cloud storage URI. -* `--continuous-backup-cloud-storage-cred-id`: If you set `--continuous-backup-location` to a cloud storage URI, set this to the name of a credential in the Couchbase Server credential store that the Backup Service can use to authenticate. -You must grant the Backup Service access to this credential. -* `--continuous-backup-interval`: How frequently, in minutes, the Backup Service copies data to the continuous backup location. +This value must a string containing either an absolute path to an NFS mount point mounted on every node or a cloud storage URI. +* `--continuous-backup-cloud-storage-cred-id`: If you set `--continuous-backup-location` to a cloud storage URI, set this to the name of a credential in the Couchbase Server credential store. +The Backup Service uses this credential to authenticate with the cloud provider. +You must also grant the Backup Service access to this credential. +* `--continuous-backup-interval`: How frequently in minutes then Backup Service copies data to the continuous backup location. When using a cloud-based storage location, lower settings for this value result in higher per-access costs. * `--continuous-backup-retention-period`: the number of hours the Backup Service keeps the continuous backup data before purging it. This value sets how far back in time you can use Point in Time Recovery (PITR). @@ -240,7 +242,6 @@ This value sets how far back in time you can use Point in Time Recovery (PITR). This URI must start with `awskms`, `azurekeyvalue`, or `gcpkms`. ** `--continuous-backup-km-cred=id`: the name of a credential in the Couchbase Server credential store that grants the Backup Service access to a KMS to manage its encryption keys. - The following example enables continuous backup on the `travel-sample` bucket. It sets the backup interval to 10 minutes and the retention period to 30 days (270 hours). The backup location is an NFS share mounted at `/shared/continuous-backup` on all nodes. @@ -248,7 +249,8 @@ The backup location is an NFS share mounted at `/shared/continuous-backup` on al [source,bash] ``` couchbase-cli bucket-edit --cluster couchbase://node1.example.com \ - --username Administrator --password password \ + --username $COUCHBASE_USERNAME \ + --password $COUCHBASE_PASSWORD \ --bucket travel-sample \ --continuous-backup-enabled 1 \ --continuous-backup-location /shared/continuous-backup \ @@ -256,11 +258,13 @@ couchbase-cli bucket-edit --cluster couchbase://node1.example.com \ --continuous-backup-retention-period 270 ``` +See the documentation for the `couchbase-cli` tool's xref:cli:cbcli/couchbase-cli-bucket-create.adoc[] and xref:cli:cbcli/couchbase-cli-bucket-edit.adoc[] commands for more information about creating and editing buckets using the command line. + ## Turning Off Continuous Backup Once enabled, you can turn off continuous backup for a bucket. You can turn off continuous backups before you do a PITR to prevent a backup from occurring during the restore. -You may also want to turn it off to prevent a point in time you may want to restore to from falling outside the retention window. +You may also want to turn it off to preserve the PITR recovery window that's currently in the continuous backup location. You can turn off continuous backup using the Couchbase Server Web Console, REST API, or command line: @@ -276,7 +280,7 @@ Using the Couchbase Server Web Console:: Using the REST API:: -Make a POST call to the `/pools/default/buckets/` endpoint and set to `false`. +Make a POST call to the `/pools/default/buckets/` endpoint and set `continuousBackupEnabled` to `false`. For example, to turn off continuous backup for the `travel-sample` bucket, use this command: + @@ -287,14 +291,14 @@ curl -X POST localhost:8091/pools/default/buckets/travel-sample \ -d continuousBackupEnabled=false ``` -Using the Ccommand Line Interface:: +Using the Command Line Interface:: Use the `couchbase-cli` tools' `edit-bucket` command with the argument `--continuous-backup-enabled 0`: [source.bash] ``` couchbase-cli bucket-edit --cluster couchbase://node1.example.com \ - --username Administrator --password password \ + --username $COUCHBASE_USERNAME --password $COUCHBASE_PASSWORD \ --bucket travel-sample \ --continuous-backup-enabled 0 ``` diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc new file mode 100644 index 0000000000..90b593e292 --- /dev/null +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -0,0 +1,74 @@ += Manage Point in Time Recovery (PITR) +:description: pass:q[Point in time recovery (PITR) lets you restore a bucket to the state it was in at a specific time.] +:enterprise-only: +:toclevels: 3 + +[abstract] +{description} +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an overview of continuous backup and point in time recovery. + +## Prerequisites + +* Your Couchbase Server account must have the xref:learn:security/roles.adoc#backup-full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. + +* You must have a Magma bucket configured with continuous backup. +See xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc[] for the steps to configure continuous backup for a Magma bucket. + +* Continuous backup must have made at least a single backup to the continuous backup location. +This means continuous backup must have been active for a bit longer than its continuous backup interval. + +* You must have a traditional periodic backups for the bucket you are restoring. +Continuous backup restores the most recent full backup taken before the pont in time you are restoring to. +It then restores any incremental backups taken between the full backup and the point in time you chose. +It uses the data in the continuous backup location to fill the gap between the last traditional backup it restored and the target point in time. + +* You must choose which point in time you want to restore the bucket to. + ++ +The earliest point in time you can restore to is determined by your continuous backup retention period. +The exception is if you enabled continuous backup more recently than the retention period. +In that case, the earliest moment you can restore to is shortly after you enabled continuous backup. +If you need to restore your cluster to a point earlier than this time, you can only restore a traditional backup, assuming you have one that covers the time you need to restore to. +However, you cannot restore to a specific point in time with traditional backup. + ++ +The latest time you can restore to is whenever the Backup Service last copied data to the continuous backup location. +This may be as far back in the past as the continuous backup iteration period you set when configuring continuous backup. +If you stopped continuous backup earlier than + ++ +See xref:manage:manage-backup-and-restore/monitor-continuous-backup.adoc#get-cont-backup-info[Get Information About a Continuous Backup Location] to learn how to find the range of time backed up by a continuous backup location. + +* You must have a bucket where you want to restore to. +This can be: ++ +-- +** The original bucket. +** A new bucket in the same cluster. +** A bucket in a different cluster. +-- ++ +PITR recovery does not flush the bucket before a restore. +The documents restored by PITR overwrite corresponding documents in the bucket. +However, documents that do not exist in the backup (such as those added after the point in time) remain in the bucket. +If you want to restore the bucket to its exact state at the point in time you choose, flush the bucket before restoring. +See xref:manage:manage-buckets/flush-bucket.adoc[] for more information about flushing buckets. + +## Restore to a Point in Time + +You use the `cbcontbk` command line tool to restore a bucket backed up using continuous backup to point in time. + +When calling `cbcontbk`, you must supply the following arguments: + +* `--target` is the date and time you want to restore the bucket to in an https://www.rfc-editor.org/info/rfc3339/[RFC3339 timestamp^]. +* `-u` and `-p` are the username and password for the full administrator. +* `--tmp-dir` a temporary directory the Backup Service can use when restoring data. +* `-l` the continuous backup storage location. +This is either the absolute path of the NFS mount point, or the URI of the cloud storage location. +* `-a` the path to the traditional backup directory. +* `-r` is the repository containing the bucket's traditional backup. +* `-c` is the URL for a node in the cluster. + +In addition, you must supply credentials to access the continuous backup location or the traditional backup repository if they are stored in the cloud. + + diff --git a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc new file mode 100644 index 0000000000..c0b2746a49 --- /dev/null +++ b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc @@ -0,0 +1,74 @@ += Monitor Continuous Backup +:description: pass:q[Once you have enabled continuous backup for a bucket, you can monitor its status.] +:enterprise-only: +:toclevels: 3 + +[abstract] +{description} +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an overview of continuous backup and point in time recovery. + +== Prerequisites + +* Your Couchbase Server account must have the xref:learn:security/roles.adoc#backup-full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. +* You must have a Magma bucket with continuous backup enabled. +See xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc[] for the steps to configure continuous backup for a Magma bucket. + + +[#get-cont-backup-info] +== Get Information About a Continuous Backup Location + +Once you have enabled continuous backup, you can get information about your backup location using the `cbcontbk` command line tool's `info` command. +The information includes the earliest and latest data in the location. + +To get the information about the location, use the command: + +[source,bash] +``` +cbcontbk info -l +``` + +Where `` is either the local path to the NFS mount or the URI of the cloud storage location where the backup is stored. +If the storage location is cloud-based, you must also supply the credentials and other settings `cbcontbk` needs to read data from the location. +See the `cbcontbk` documentation for details. + +// FIXME: link to cbcontbk docs when they are available. + +The following example gets information about the continuous backup location stored on an NFS share mounted at `/shared/continuous-backup` on all nodes in the cluster. + +[source,bash] +``` +cbcontbk info -l /shared/continuous-backup/ +``` + +The following example shows the output of the previous command for a location backing up the `travel-sample` bucket. + +[source,bash] +``` +| Buckets +| ------- +| +| * Bucket +| ------ +| Name | UUID | +| travel-sample | b5de13bdc656985b0a41dd3d832c9be6 | +| +| Range +| ----- +| Start | End | +| 2026-06-05T14:57:18Z | 2026-06-05T17:55:22Z | +| +``` + +The timestamps under the Range heading in the output show you the earliest and latest times you can restore the bucket to using point in time recovery (PITR). +See xref:manage:manage-backup-and-restore/manage-pitr.adoc[] for more information about performing a PITR. + +## Continuous Backup Metrics + +Continuous backup exposes several metrics that let you monitor its status. +You can use these metrics to monitor its status in tools such as Prometheus. +These metrics all start with the `contbk_` (continuous backup) prefix. + +// FIXME: link to metrics whenever they show up in the metrics_metadata file in the server build.. They aren't there as of build #2395 + +For more information about monitoring Couchbase Server using metrics, see xref:current:manage/monitor/set-up-prometheus-for-monitoring.adoc[]. + diff --git a/modules/metrics-reference/attachments/cm_metrics_metadata.json b/modules/metrics-reference/attachments/cm_metrics_metadata.json index acbc6eda43..92a0aaa874 100644 --- a/modules/metrics-reference/attachments/cm_metrics_metadata.json +++ b/modules/metrics-reference/attachments/cm_metrics_metadata.json @@ -507,6 +507,18 @@ "stability": "internal", "type": "counter" }, + "cm_lighthouse_telemetry_sends_total": { + "added": "7.6.12", + "help": "Number of times lighthouse telemetry sends were attempted", + "labels": [ + { + "help": "Whether the report was a success or a failure", + "name": "result" + } + ], + "stability": "internal", + "type": "counter" + }, "cm_logs_total": { "added": "7.1.0", "help": "Total number of logs logged", diff --git a/modules/metrics-reference/attachments/fts_metrics_metadata.json b/modules/metrics-reference/attachments/fts_metrics_metadata.json index 8518a3e178..7803c24f9c 100644 --- a/modules/metrics-reference/attachments/fts_metrics_metadata.json +++ b/modules/metrics-reference/attachments/fts_metrics_metadata.json @@ -989,6 +989,16 @@ ], "type": "counter" }, + "fts_total_vector_indexes_in_cpu": { + "added": "8.1.0", + "help": "The total number of segmented vector indexes currently loaded in CPU memory", + "type": "gauge" + }, + "fts_total_vector_indexes_in_gpu": { + "added": "8.1.0", + "help": "The total number of segmented vector indexes currently loaded in GPU memory", + "type": "gauge" + }, "fts_total_vectors": { "added": "7.6.1", "help": "The total number of vectors indexed", diff --git a/modules/metrics-reference/attachments/goxdcr_metrics_metadata.json b/modules/metrics-reference/attachments/goxdcr_metrics_metadata.json index 2c72cbf0cc..45ab299913 100644 --- a/modules/metrics-reference/attachments/goxdcr_metrics_metadata.json +++ b/modules/metrics-reference/attachments/goxdcr_metrics_metadata.json @@ -770,25 +770,27 @@ }, "xdcr_docs_sent_with_subdoc_delete_total": { "added": "7.6.6", - "help": "The number of deletes issued using subdoc command instead of delete_with_meta to avoid cas rollback on target", + "help": "The number of deletes issued using subdoc (or MutateWithMeta) command instead of delete_with_meta to avoid cas rollback on target", "labels": [ "sourceBucketName", "targetClusterUUID", "targetBucketName", "pipelineType" ], + "notes": "MutateWithMeta is used when both source and target cluster are 8.1+. Subdoc command is used otherwise", "stability": "committed", "type": "counter" }, "xdcr_docs_sent_with_subdoc_set_total": { "added": "7.6.6", - "help": "The number of sets issued using subdoc command instead of set_with_meta to avoid cas rollback on target", + "help": "The number of sets issued using subdoc (or MutateWithMeta) command instead of set_with_meta to avoid cas rollback on target", "labels": [ "sourceBucketName", "targetClusterUUID", "targetBucketName", "pipelineType" ], + "notes": "MutateWithMeta is used when both source and target cluster are 8.1+. Subdoc command is used otherwise", "stability": "committed", "type": "counter" }, @@ -1269,7 +1271,7 @@ "type": "counter" }, "xdcr_non_local_mutations_skipped_total": { - "added": "8.1.0", + "added": "8.0.2", "help": "Number of document mutations that were not batched for replication to Target because they did not qualify as 'local' for the 'forwardLocalOnly' replication", "labels": [ "sourceBucketName", @@ -1505,7 +1507,7 @@ ], "notes": "One source node will be responsible to send heartbeat to one target node. This stats will accumulate only if this particular node received data", "stability": "internal", - "type": "gauge", + "type": "counter", "unit": "bytes" }, "xdcr_source_sync_xattr_removed_total": { diff --git a/modules/metrics-reference/attachments/index_metrics_metadata.json b/modules/metrics-reference/attachments/index_metrics_metadata.json index 7fc98c6378..96dc374b68 100644 --- a/modules/metrics-reference/attachments/index_metrics_metadata.json +++ b/modules/metrics-reference/attachments/index_metrics_metadata.json @@ -235,6 +235,26 @@ "help": "Average index scan rate across all indexes, for this node", "type": "gauge" }, + "index_num_bhive_dense_indexes": { + "added": "8.1.0", + "help": "Total number of bhive indexes without sparse vector, located on this node", + "type": "gauge" + }, + "index_num_bhive_sparse_indexes": { + "added": "8.1.0", + "help": "Total number of bhive indexes with sparse vector, located on this node", + "type": "gauge" + }, + "index_num_composite_dense_indexes": { + "added": "8.1.0", + "help": "Total number of composite indexes without sparse vector, located on this node", + "type": "gauge" + }, + "index_num_composite_sparse_indexes": { + "added": "8.1.0", + "help": "Total number of composite indexes with sparse vector, located on this node", + "type": "gauge" + }, "index_num_diverging_replica_indexes": { "added": "8.0.0", "help": "Number of index partitions with diverging replica item counts.", diff --git a/modules/metrics-reference/attachments/kv_metrics_metadata.json b/modules/metrics-reference/attachments/kv_metrics_metadata.json index c8089a023d..d2980c4e94 100644 --- a/modules/metrics-reference/attachments/kv_metrics_metadata.json +++ b/modules/metrics-reference/attachments/kv_metrics_metadata.json @@ -652,6 +652,7 @@ "kv_ep_cache_size": { "added": "7.0.0", "help": "Memory quota (in bytes) for this bucket.", + "long_description": "Provides the absolute maximum amount of memory, measured in bytes, allocated to a specific bucket on a single node. It represents the hard memory quota configured by the administrator, serving as the strict baseline for calculating critical thresholds like high and low watermarks. This value is critical for capacity planning.", "stability": "volatile", "type": "gauge" }, @@ -705,6 +706,7 @@ "kv_ep_checkpoint_memory_ratio": { "added": "7.0.0", "help": "Max ratio of the bucket quota that can be allocated in checkpoints. The system enters a TempOOM phase if hit.", + "long_description": "Provides the maximum percentage of the bucket's memory quota dedicated to checkpoints. When this ratio is hit, the system enters a temporary TempOOM phase and immediately triggers memory recovery to minimize the duration of TempOOM state. A checkpoint is a sequenced queue of mutations that acts as the single source of truth for both persistence and replication within a bucket. Persistence and replication consume from this queue independently, each progressing at its own pace without coordinating with the other. The checkpoint queue allow disk flusher and DCP consumers to read from the same data structure to ensure consistency. This value helps ensure efficient memory utilization.", "stability": "volatile", "type": "gauge" }, @@ -956,6 +958,12 @@ "stability": "committed", "type": "gauge" }, + "kv_ep_dcp_active_stream_inline_checkpoint_item_limit": { + "added": "7.0.0", + "help": "When the number of items pending for an ActiveStream's cursor is less than or equal to this value, the stream will run checkpoint item extraction inline rather than scheduling the ActiveStreamCheckpointProcessorTask. This avoids task-scheduling latency for small numbers of items. Set to 0 to always schedule the task.", + "stability": "volatile", + "type": "gauge" + }, "kv_ep_dcp_backfill_byte_drain_ratio": { "added": "7.0.0", "help": "What ratio of the dcp_backfill_byte_limit must be drained for un-pausing a paused backfill", @@ -982,7 +990,7 @@ }, "kv_ep_dcp_backfill_idle_protection_enabled": { "added": "7.0.0", - "help": "When true, DCP backfills will be checked for progress. Any backfill which makes no progress for dcp_backfill_idle_limit_seconds will be subject to further checks. If the directory referenced by dbname is over dcp_backfill_idle_disk_threshold percent used and cancelling the backfill will free disk space, the scan cancels and the associated DCP stream will end with reason slow.", + "help": "When true, DCP backfills will be checked for progress. Any backfill which makes no progress for dcp_backfill_idle_limit_seconds will be subject to further checks. If the directory referenced by dbname is over dcp_backfill_idle_disk_threshold percent used and cancelling the backfill will free disk space, the scan cancels and the associated DCP stream will end with reason slow. This is ignored for emphemeral buckets", "stability": "volatile", "type": "gauge" }, @@ -1010,6 +1018,12 @@ "stability": "volatile", "type": "gauge" }, + "kv_ep_dcp_cache_transfer_max_batch_bytes": { + "added": "7.0.0", + "help": "Maximum batch size in bytes for batching cache transfer items. At least 1 item will included in a batch, so a value of 0 is always 1 item per batch.", + "stability": "volatile", + "type": "gauge" + }, "kv_ep_dcp_cache_transfer_one_visit_per_step": { "added": "7.0.0", "help": "Set to false for simpler unit-testing. When true CacheTransferTask to visit the hash table many times per step, when false one item per task step", @@ -1597,6 +1611,13 @@ "type": "counter", "unit": "count" }, + "kv_ep_fusion_pending_upload_bytes_bytes": { + "added": "8.1.0", + "help": "Total amount of data not yet synced to FusionLogStore.", + "stability": "committed", + "type": "gauge", + "unit": "bytes" + }, "kv_ep_fusion_sync_attempts": { "added": "8.1.0", "help": "Total number of sync attempts to Fusion including both successful and failed attempts.", @@ -1931,6 +1952,30 @@ "stability": "volatile", "type": "gauge" }, + "kv_ep_magma_bloom_filter_cache_hits": { + "added": "8.1.0", + "help": "Number of bloom filter lookups served from the in-memory bloom filter cache", + "stability": "committed", + "type": "counter" + }, + "kv_ep_magma_bloom_filter_cache_misses": { + "added": "8.1.0", + "help": "Number of bloom filter lookups that required a disk read", + "stability": "committed", + "type": "counter" + }, + "kv_ep_magma_bloom_filter_lookups_hit": { + "added": "8.1.0", + "help": "Number of bloom filter lookups where the filter correctly indicated the key did not exist", + "stability": "committed", + "type": "counter" + }, + "kv_ep_magma_bloom_filter_lookups_miss": { + "added": "8.1.0", + "help": "Number of bloom filter lookups where the filter returned a false positive", + "stability": "committed", + "type": "counter" + }, "kv_ep_magma_bloom_filter_mem_used_bytes": { "added": "7.1.0", "help": "Bloom filter memory usage in all versions of the LSM Trees", @@ -1998,6 +2043,48 @@ "stability": "committed", "type": "gauge" }, + "kv_ep_magma_contbk_num_backup_hardlinks": { + "added": "8.1.0", + "help": "Number of file hardlinks that have occurred as a part of backup", + "stability": "committed", + "type": "counter", + "unit": "count" + }, + "kv_ep_magma_contbk_num_backups": { + "added": "8.1.0", + "help": "Number of Backups that have occurred", + "stability": "committed", + "type": "counter", + "unit": "count" + }, + "kv_ep_magma_contbk_num_bytes_written_bytes": { + "added": "8.1.0", + "help": "Number of bytes written as a part of the backup", + "stability": "committed", + "type": "gauge", + "unit": "bytes" + }, + "kv_ep_magma_contbk_num_failed_backups": { + "added": "8.1.0", + "help": "Number of Backups that have failed", + "stability": "committed", + "type": "counter", + "unit": "count" + }, + "kv_ep_magma_contbk_num_table_bytes_backedup_bytes": { + "added": "8.1.0", + "help": "Number of Table Bytes that have been backed up", + "stability": "committed", + "type": "gauge", + "unit": "bytes" + }, + "kv_ep_magma_contbk_num_write_ios": { + "added": "8.1.0", + "help": "Number of Write IOs that have occurred as a part of backup", + "stability": "committed", + "type": "counter", + "unit": "count" + }, "kv_ep_magma_corruption_errors": { "added": "8.1.0", "help": "Number of corruption errors detected by Magma", @@ -2292,6 +2379,12 @@ "type": "gauge", "unit": "bytes" }, + "kv_ep_magma_max_base_level_size": { + "added": "7.0.0", + "help": "Upper bound on the dynamic L0/L1 target size. The target scales with the bottom level; values above this are clamped.", + "stability": "volatile", + "type": "gauge" + }, "kv_ep_magma_max_checkpoints": { "added": "7.0.0", "help": "Maximum # of checkpoints retained for rollback.", @@ -2304,6 +2397,12 @@ "stability": "volatile", "type": "gauge" }, + "kv_ep_magma_max_num_level0_tables": { + "added": "7.0.0", + "help": "Maximum number of L0 tables in the magma LSM trees.", + "stability": "volatile", + "type": "gauge" + }, "kv_ep_magma_max_recovery_bytes": { "added": "7.0.0", "help": "Maximum amount of data that is replayed from the WAL during magma recovery. When this threshold is reached magma, creates a temporary checkpoint to recover at. This is per kvstore and in bytes.", @@ -2406,6 +2505,18 @@ "stability": "committed", "type": "gauge" }, + "kv_ep_magma_readio_get": { + "added": "8.1.0", + "help": "Number of read IOs performed on the get path", + "stability": "committed", + "type": "counter" + }, + "kv_ep_magma_readio_set": { + "added": "8.1.0", + "help": "Number of read IOs performed on the set path", + "stability": "committed", + "type": "counter" + }, "kv_ep_magma_readioamp_ratio": { "added": "7.1.0", "help": "Number of read IOs performed by GetDocs divided by the number of GetDocs", @@ -2632,6 +2743,7 @@ "kv_ep_max_size": { "added": "7.0.0", "help": "Memory quota (in bytes) for this bucket.", + "long_description": "Provides the absolute maximum amount of memory, measured in bytes, allocated to a specific bucket on a single node. It represents the hard memory quota configured by the administrator, serving as the strict baseline for calculating critical thresholds like high and low watermarks. This value is critical for capacity planning.", "stability": "volatile", "type": "gauge" }, @@ -2676,6 +2788,7 @@ "kv_ep_mem_high_wat_percent": { "added": "7.0.0", "help": "Ratio of the Bucket Quota at which to place the high watermark. This is the maximum desired memory usage. This value should be lower than mutation_mem_ratio to avoid no memory errors.", + "long_description": "Provides the specific percentage of the total bucket memory quota that acts as the high watermark threshold. By default, the high watermark is set at 85% of the bucket's allocated memory. It represents the critical trigger point where the engine proactively initiates background memory management routines to evict data from RAM to disk until memory usage drops below the low watermark. This value is vital for identifying heavy memory pressure.", "stability": "volatile", "type": "gauge" }, @@ -2688,6 +2801,7 @@ "kv_ep_mem_low_wat_percent": { "added": "7.0.0", "help": "Ratio of the Bucket Quota at which to place the low watermark. This is the point to which to reduce the memory usage of the bucket after hitting the high watermark.", + "long_description": "Provides the specific percentage of the maximum bucket memory quota designated as the low watermark. By default it is set at 10% lower than the high watermark. It represents the target recovery threshold for the item pager, indicating the point at which continuous eviction from memory to disk ceases after a high watermark breach. This value ensures a healthy buffer of free memory.", "stability": "volatile", "type": "gauge" }, @@ -2723,9 +2837,16 @@ "stability": "volatile", "type": "gauge" }, + "kv_ep_monitor_task_interval": { + "added": "7.0.0", + "help": "Schedule interval (in seconds) for the MonitorTask.", + "stability": "volatile", + "type": "gauge" + }, "kv_ep_mutation_mem_ratio": { "added": "7.0.0", "help": "Ratio of the Bucket Quota that can be used before mutations return tmpOOMs", + "long_description": "Provides the precise percentage of the maximum bucket memory quota beyond which the engine will begin to reject frontend mutations with temporary OOM errors. It is set at a default of 93%. It represents a protective throttling threshold, indicating the system is nearing complete memory exhaustion and must temporarily block incoming writes. It is a dynamic value that can be modified. This value protects the node from allocating beyond the assigned bucket quota. It prevent crashes in the cases like high memory fragmentation where memcached memory usage is higher than logical allocation.", "stability": "volatile", "type": "gauge" }, @@ -2915,6 +3036,7 @@ "kv_ep_persistent_metadata_purge_age": { "added": "7.0.0", "help": "Age in seconds after which tombstones may be purged. Defaults to 3 days. Max of 60 days. If this is dynamically changed for a magma bucket then magma may not trigger compactions when it should, this can be avoided by running a full manual compaction after changing this parameter.", + "long_description": "Provides the configured time interval after which the persistent metadata of deleted items, known as tombstones, is permanently purged from disk storage. It represents the active policy for tombstone expiration, balancing robust replication consistency against disk space reclamation. This value is crucial for tuning storage overhead.", "stability": "volatile", "type": "gauge" }, @@ -3260,13 +3382,6 @@ "stability": "volatile", "type": "gauge" }, - "kv_ephemeral_vb_checkpoint_memory_overhead_bytes": { - "added": "7.6.0", - "help": "Total memory overhead of all checkpoints", - "stability": "internal", - "type": "gauge", - "unit": "bytes" - }, "kv_ephemeral_vb_ht_memory_bytes": { "added": "7.6.0", "help": "Total memory used by HashTable items", @@ -3281,16 +3396,23 @@ "type": "counter", "unit": "bytes" }, + "kv_fusion_deferred_upload_bytes_bytes": { + "added": "8.1.0", + "help": "The amount of data Fusion knows is pending sync but has decided to defer in order to reduce the number of uploads to FusionLogStore", + "stability": "committed", + "type": "gauge", + "unit": "bytes" + }, "kv_fusion_max_pending_upload_bytes_bytes": { "added": "8.1.0", - "help": "The maximum number of pending upload bytes to be synced across all volumes.", + "help": "Configuration value for the maximum amount of pending upload bytes across all volumes.", "stability": "committed", "type": "gauge", "unit": "bytes" }, "kv_fusion_max_pending_upload_bytes_lwm_ratio": { "added": "8.1.0", - "help": "The proportion of max_pending_upload_bytes beyond which syncs for volumes with highest pending bytes are only allowed.", + "help": "Configuration value for the proportion of max_pending_upload_bytes beyond which syncs for volumes with highest pending bytes are only allowed.", "stability": "committed", "type": "gauge" }, @@ -3315,13 +3437,6 @@ "type": "gauge", "unit": "bytes" }, - "kv_fusion_pending_upload_bytes_bytes": { - "added": "8.1.0", - "help": "The total pending upload bytes across all fusion volumes.", - "stability": "committed", - "type": "gauge", - "unit": "bytes" - }, "kv_fusion_sync_rate_limit_bytes": { "added": "8.0.0", "help": "The rate limit for fusion sync uploads, in bytes per second.", @@ -3410,13 +3525,13 @@ "type": "gauge" }, "kv_magma_num_compactor_threads": { - "added": "8.1.0", + "added": "7.6.11", "help": "The number of magma compactor threads.", "stability": "committed", "type": "gauge" }, "kv_magma_num_flusher_threads": { - "added": "8.1.0", + "added": "7.6.11", "help": "The number of magma flusher threads.", "stability": "committed", "type": "gauge" @@ -3456,6 +3571,7 @@ "kv_mem_used_bytes": { "added": "7.0.0", "help": "Engine's total memory usage", + "long_description": "Provides the most comprehensive view of bucket memory consumption. It is used for quota enforcement, eviction decisions, and monitoring memory pressure. It is calculated using jemalloc's ArenaMalloc. The metric includes (1) Item data (item metadata, keys, resident and non-resident values); (2) Structural overhead (checkpoint queues, persistence queues, DCP queues, hash table and collections/scope metadata); and (3) Component allocations (Magma storage buffers, bloom filters, durability monitor memory, arena allocator overhead and any other internal allocations).", "stability": "committed", "type": "gauge", "unit": "bytes" @@ -3529,6 +3645,19 @@ "stability": "committed", "type": "counter" }, + "kv_pager_deleted_bytes": { + "added": "7.6.11", + "help": "Number of bytes deleted by pager", + "stability": "committed", + "type": "gauge", + "unit": "bytes" + }, + "kv_pager_throttled": { + "added": "7.6.11", + "help": "Total number of times pager has been throttled", + "stability": "committed", + "type": "counter" + }, "kv_read_bytes": { "added": "7.0.0", "help": "The number bytes received from all connections bound to this bucket", @@ -3685,6 +3814,12 @@ "type": "gauge", "unit": "seconds" }, + "kv_tls_certificate_verification_problems": { + "added": "totoro", + "help": "The number of times TLS certificate verification has found issues with the certificate presented by the client during connection establishment", + "stability": "committed", + "type": "gauge" + }, "kv_total_connections": { "added": "7.0.0", "help": "The total number of connections to this system since the process started (or reset)", diff --git a/modules/metrics-reference/attachments/n1ql_metrics_metadata.json b/modules/metrics-reference/attachments/n1ql_metrics_metadata.json index 4f6a7f6b19..a9ea5ff49b 100644 --- a/modules/metrics-reference/attachments/n1ql_metrics_metadata.json +++ b/modules/metrics-reference/attachments/n1ql_metrics_metadata.json @@ -89,6 +89,11 @@ "help": "Count of CAS mismatch errors", "type": "counter" }, + "n1ql_chats": { + "added": "8.1.0", + "help": "Total number of natural language chats.", + "type": "counter" + }, "n1ql_counter_cu_total": { "added": "7.6.0", "help": "The number of distinct operations recording Compute Units (CUs) with Regulator.", @@ -235,6 +240,11 @@ "type": "counter", "uiName": "N1QL Error Rate" }, + "n1ql_external_scans": { + "added": "8.1.0", + "help": "Total number of external collection scans.", + "type": "counter" + }, "n1ql_ffdc_manual": { "added": "7.6.6", "help": "The total number of ffdc captures triggered due to manual invocation of ffdc admin api", @@ -717,11 +727,26 @@ "uiName": "Query Execution Time", "unit": "nanoseconds" }, + "n1ql_spills_merge": { + "added": "7.6.12", + "help": "Number of merge operations that have spilled to disk.", + "type": "counter" + }, "n1ql_spills_order": { - "added": "8.0.0", + "added": "7.6.12", "help": "Number of order by operations that have spilled to disk.", "type": "counter" }, + "n1ql_spills_seq_scan": { + "added": "7.6.12", + "help": "Number of sequential scans that have spilled to disk.", + "type": "counter" + }, + "n1ql_spills_update_statistics": { + "added": "7.6.12", + "help": "Number of statistics update operations that have spilled to disk.", + "type": "counter" + }, "n1ql_svi_request_timer_15m_rate": { "added": "8.0.0", "help": "The 15m.rate latency of SQL++ FTS VECTOR requests.", diff --git a/preview/DOC-12561_Continuous_backup_PITR.yml b/preview/DOC-12561_Continuous_backup_PITR.yml index bfbba5c0b2..a191863262 100644 --- a/preview/DOC-12561_Continuous_backup_PITR.yml +++ b/preview/DOC-12561_Continuous_backup_PITR.yml @@ -10,9 +10,9 @@ sources: branches: master startPaths: docs/ -# backup: -# branches: master -# startPaths: docs/ + backup: + branches: master + startPaths: docs/ cb-swagger: url: https://github.com/couchbaselabs/cb-swagger From 0e8a30554876d2680d533d826bbdc5e033e84c9e Mon Sep 17 00:00:00 2001 From: Gary Gray Date: Wed, 1 Jul 2026 14:40:26 -0400 Subject: [PATCH 05/28] Wrapped up draft of PITR page. --- modules/manage/examples/continuous-backup.log | 150 ++++++++++++++++++ modules/manage/examples/continuous-backup.sh | 15 ++ .../manage-continuous-backup.adoc | 9 +- .../manage-pitr.adoc | 120 +++++++++++++- .../monitor-continuous-backup.adoc | 20 +-- 5 files changed, 288 insertions(+), 26 deletions(-) create mode 100644 modules/manage/examples/continuous-backup.log create mode 100644 modules/manage/examples/continuous-backup.sh diff --git a/modules/manage/examples/continuous-backup.log b/modules/manage/examples/continuous-backup.log new file mode 100644 index 0000000000..5af6911e66 --- /dev/null +++ b/modules/manage/examples/continuous-backup.log @@ -0,0 +1,150 @@ +# Result of getting continuous backup info +# tag::get-backup-info[] +| Buckets +| ------- +| +| * Bucket +| ------ +| Name | UUID | +| travel-sample | b5de13bdc656985b0a41dd3d832c9be6 | +| +| Range +| ----- +| Start | End | +| 2026-06-05T14:57:18Z | 2026-06-23T17:55:22Z | +| +# end::get-backup-info[] + +# tag::restore-output[] +Warning: Restore has skipped some users and/or groups. Please check the logs for more information. +(1/6) Restoring backup '2026-06-05T14_07_44.644199759Z' +Copied all data in 2.196s (Avg. 20.72MiB/Sec) 63288 items / 41.43MiB +[===========================================================================================================================================] 100.00% + +| Transfer +| -------- +| Status | Avg Transfer Rate | Started At | Finished At | Duration | +| Succeeded | 20.72MiB/s | Tue, 09 Jun 2026 18:28:44 +0000 | Tue, 09 Jun 2026 18:28:46 +0000 | 2.274s | + +| Bucket +| ------ +| Name | Status | Transferred | Avg Transfer Rate | Started At | Finished At | Duration | +| travel-sample | Succeeded | 41.43MiB | 41.43MiB/s | Tue, 09 Jun 2026 18:28:45 +0000 | Tue, 09 Jun 2026 18:28:46 +0000 | 1.939s | +| +| Mutations | Deletions | Expirations | +| --------- | --------- | ----------- | +| Received | Errored | Skipped | Received | Errored | Skipped | Received | Errored | Skipped | +| 63288 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | + +Warning: Restore has skipped some users and/or groups. Please check the logs for more information. +(2/6) Restoring backup '2026-06-05T15_30_24.625814389Z' +Copied all data in 2.599s (Avg. 206.57KiB/Sec) 619 items / 413.14KiB +[===========================================================================================================================================] 100.00% + +| Transfer +| -------- +| Status | Avg Transfer Rate | Started At | Finished At | Duration | +| Succeeded | 206.57KiB/s | Tue, 09 Jun 2026 18:28:44 +0000 | Tue, 09 Jun 2026 18:28:47 +0000 | 2.663s | + +| Bucket +| ------ +| Name | Status | Transferred | Avg Transfer Rate | Started At | Finished At | Duration | +| travel-sample | Succeeded | 413.14KiB | 413.14KiB/s | Tue, 09 Jun 2026 18:28:47 +0000 | Tue, 09 Jun 2026 18:28:47 +0000 | 177ms | +| +| Mutations | Deletions | Expirations | +| --------- | --------- | ----------- | +| Received | Errored | Skipped | Received | Errored | Skipped | Received | Errored | Skipped | +| 369 | 0 | 0 | 250 | 0 | 0 | 0 | 0 | 0 | + +Warning: Restore has skipped some users and/or groups. Please check the logs for more information. +(3/6) Restoring backup '2026-06-05T16_37_54.174811004Z' +Copied all data in 2.991s (Avg. 143.06KiB/Sec) 303 items / 286.13KiB +[===========================================================================================================================================] 100.00% + +| Transfer +| -------- +| Status | Avg Transfer Rate | Started At | Finished At | Duration | +| Succeeded | 95.38KiB/s | Tue, 09 Jun 2026 18:28:44 +0000 | Tue, 09 Jun 2026 18:28:47 +0000 | 3.042s | + +| Bucket +| ------ +| Name | Status | Transferred | Avg Transfer Rate | Started At | Finished At | Duration | +| travel-sample | Succeeded | 286.13KiB | 286.13KiB/s | Tue, 09 Jun 2026 18:28:47 +0000 | Tue, 09 Jun 2026 18:28:47 +0000 | 172ms | +| +| Mutations | Deletions | Expirations | +| --------- | --------- | ----------- | +| Received | Errored | Skipped | Received | Errored | Skipped | Received | Errored | Skipped | +| 233 | 0 | 0 | 70 | 0 | 0 | 0 | 0 | 0 | + +Warning: Restore has skipped some users and/or groups. Please check the logs for more information. +(4/6) Restoring backup '2026-06-05T18_30_56.913953884Z' +Copied all data in 3.461s (Avg. 241.02KiB/Sec) 910 items / 723.06KiB +[===========================================================================================================================================] 100.00% + +| Transfer +| -------- +| Status | Avg Transfer Rate | Started At | Finished At | Duration | +| Succeeded | 241.02KiB/s | Tue, 09 Jun 2026 18:28:44 +0000 | Tue, 09 Jun 2026 18:28:48 +0000 | 3.498s | + +| Bucket +| ------ +| Name | Status | Transferred | Avg Transfer Rate | Started At | Finished At | Duration | +| travel-sample | Succeeded | 723.06KiB | 723.06KiB/s | Tue, 09 Jun 2026 18:28:47 +0000 | Tue, 09 Jun 2026 18:28:48 +0000 | 243ms | +| +| Mutations | Deletions | Expirations | +| --------- | --------- | ----------- | +| Received | Errored | Skipped | Received | Errored | Skipped | Received | Errored | Skipped | +| 633 | 0 | 0 | 277 | 0 | 0 | 0 | 0 | 0 | + +Warning: Restore has skipped some users and/or groups. Please check the logs for more information. +(5/6) Restoring backup '2026-06-05T19_30_57.726884217Z' +Copied all data in 5.093s (Avg. 11.28KiB/Sec) 54 items / 56.39KiB +[===========================================================================================================================================] 100.00% + +| Transfer +| -------- +| Status | Avg Transfer Rate | Started At | Finished At | Duration | +| Succeeded | 11.28KiB/s | Tue, 09 Jun 2026 18:28:44 +0000 | Tue, 09 Jun 2026 18:28:49 +0000 | 5.119s | + +| Bucket +| ------ +| Name | Status | Transferred | Avg Transfer Rate | Started At | Finished At | Duration | +| travel-sample | Succeeded | 56.39KiB | 56.39KiB/s | Tue, 09 Jun 2026 18:28:49 +0000 | Tue, 09 Jun 2026 18:28:49 +0000 | 117ms | +| +| Mutations | Deletions | Expirations | +| --------- | --------- | ----------- | +| Received | Errored | Skipped | Received | Errored | Skipped | Received | Errored | Skipped | +| 44 | 0 | 0 | 10 | 0 | 0 | 0 | 0 | 0 | + +(6/6) Restoring backup 'Continuous' +Copied all data in 5.316s (Avg. 378B/Sec) 0 items / 1.85KiB +[===========================================================================================================================================] 100.00% + +| Transfer +| -------- +| Status | Avg Transfer Rate | Started At | Finished At | Duration | +| Succeeded | 378B/s | Tue, 09 Jun 2026 18:28:44 +0000 | Tue, 09 Jun 2026 18:28:50 +0000 | 5.454s | + +| Bucket +| ------ +| Name | Status | Transferred | Avg Transfer Rate | Started At | Finished At | Duration | +| travel-sample | Succeeded | 1.85KiB | 1.85KiB/s | Tue, 09 Jun 2026 18:28:50 +0000 | Tue, 09 Jun 2026 18:28:50 +0000 | 91ms | +| +| Mutations | Deletions | Expirations | +| --------- | --------- | ----------- | +| Received | Errored | Skipped | Received | Errored | Skipped | Received | Errored | Skipped | +| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +root@node1:/# cbcontbk info -l /shared/continuous-backup/ +| Buckets +| ------- +| +| * Bucket +| ------ +| Name | UUID | +| travel-sample | b5de13bdc656985b0a41dd3d832c9be6 | +| +| Range +| ----- +| Start | End | +| 2026-06-05T14:57:18Z | 2026-06-09T14:54:10Z | +# end::restore-output[] \ No newline at end of file diff --git a/modules/manage/examples/continuous-backup.sh b/modules/manage/examples/continuous-backup.sh new file mode 100644 index 0000000000..cc0bd8562a --- /dev/null +++ b/modules/manage/examples/continuous-backup.sh @@ -0,0 +1,15 @@ +# Get information about the continuous backup location +# tag::get-backup-info[] +cbcontbk info -l /shared/continuous-backup/ +# end::get-backup-info[] + +# Restore the bucket +# tag::restore-bucket[] +cbcontbk restore --target 2026-06-08T19:54:10Z \ + -u $COUCHBASE_USERNAME -p $COUCHBASE_PASSWORD \ + --tmp-dir /scratch \ + -l /shared/continuous-backup/ \ + -a /shared/backups \ + -r 1c48c43c-45b8-4155-8352-7d21523b2603 \ + -c couchbase://node3.example.com +# end::restore-bucket[] \ No newline at end of file diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index 940169c1ce..0841bf2d6b 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -260,11 +260,12 @@ couchbase-cli bucket-edit --cluster couchbase://node1.example.com \ See the documentation for the `couchbase-cli` tool's xref:cli:cbcli/couchbase-cli-bucket-create.adoc[] and xref:cli:cbcli/couchbase-cli-bucket-edit.adoc[] commands for more information about creating and editing buckets using the command line. -## Turning Off Continuous Backup +[#stop-continuous-backup] +## Stop Continuous Backup -Once enabled, you can turn off continuous backup for a bucket. -You can turn off continuous backups before you do a PITR to prevent a backup from occurring during the restore. -You may also want to turn it off to preserve the PITR recovery window that's currently in the continuous backup location. +Once enabled, you can stop continuous backup for a bucket. +You must must continuous backups before you do a PITR to prevent a backup from occurring during the restore. +You may also want to stop it to preserve the PITR recovery window that's currently in the continuous backup location. You can turn off continuous backup using the Couchbase Server Web Console, REST API, or command line: diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc index 90b593e292..6b5d672646 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -49,11 +49,18 @@ This can be: -- + PITR recovery does not flush the bucket before a restore. -The documents restored by PITR overwrite corresponding documents in the bucket. -However, documents that do not exist in the backup (such as those added after the point in time) remain in the bucket. +By default, it does not overwrite existing documents already in the bucket. If you want to restore the bucket to its exact state at the point in time you choose, flush the bucket before restoring. See xref:manage:manage-buckets/flush-bucket.adoc[] for more information about flushing buckets. +* To prevent consistency issues, stop continuous backup on the bucket you're restoring. +You must stop continuous backup even if you're not restoring to the original bucket. +Once the PITR finishes, you can restart continuous backup. +See xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc#stop-continuous-backup[Stop Continuous Backup] to learn how to stop continuous backup for a bucket. + +NOTE: You do not need to stop traditional periodic backups or XDCR for the bucket when performing PITR. + + ## Restore to a Point in Time You use the `cbcontbk` command line tool to restore a bucket backed up using continuous backup to point in time. @@ -65,10 +72,111 @@ When calling `cbcontbk`, you must supply the following arguments: * `--tmp-dir` a temporary directory the Backup Service can use when restoring data. * `-l` the continuous backup storage location. This is either the absolute path of the NFS mount point, or the URI of the cloud storage location. -* `-a` the path to the traditional backup directory. -* `-r` is the repository containing the bucket's traditional backup. -* `-c` is the URL for a node in the cluster. +* `-a` the path to the traditional backup directory or its . +* `-r` is the UUID for the repository containing the bucket's traditional backup. +* `-c` is the URL for a node in the cluster running the backup service. + +In addition, you must supply credentials the Backup Service can use to authenticate with the continuous backup location and the traditional backup repository if they're stored in the cloud. +You have encrypted backups, you must also supply credentials to decrypt them. +See the documentation for `cbcontbk` for details. + +// FIXME: add link to `cbcontbk` docs when they are available in the repo. + +For example, suppose you want to restore the `travel-sample` bucket that uses locally mounted NFS shares for continuous backup and traditional backup. +Also suppose you want to restore to the original bucket and want the bucket to be in the state it was in at your chosen restoration time. +In that case, you can follow these steps to perform the PITR: + +. Stop continuous backup for the bucket. +Because you'll need to use the command line to run `cbcontbk` anyhow, this example uses command line on one of the nodes to stop continuous backup: + ++ +[source,bash] +``` +couchbase-cli bucket-edit --cluster couchbase://localhost \ + --username $COUCHBASE_USERNAME --password $COUCHBASE_PASSWORD \ + --bucket travel-sample \ + --continuous-backup-enabled 0 +``` + +. In this example, the goal is to have the bucket to be the exact state it was at the recovery time. +Therefore, you need to flush the bucket before performing PITR. + ++ +[source,bash] +``` +couchbase-cli bucket-flush --cluster couchbase://localhost \ + --username $COUCHBASE_USERNAME --password $COUCHBASE_PASSWORD \ + --bucket travel-sample +``` + ++ +[NOTE] +==== +The previous example assumes the bucket is already configured to allow flushing. +If it's not, you must first enable flushing using the command: + +[source,bash] +``` +couchbase-cli bucket-edit --cluster couchbase://localhost \ + --username $COUCHBASE_USERNAME --password $COUCHBASE_PASSWORD \ + --bucket travel-sample \ + --enable-flush 1 +``` + +After finishing the PITR, consider tunring off flushing the bucket again to prevent accidental data loss. +==== + +. Before performing the restore, you should verify the point in time you want to restore to is available in the continuous backup location. +You can find the range of times you can restore to using the `cbcontbk` command line tool. -In addition, you must supply credentials to access the continuous backup location or the traditional backup repository if they are stored in the cloud. ++ +[source,bash] +``` +include::manage:example$continuous-backup.sh[tag=get-backup-info] +``` + ++ +The result of the previous command looks like the following: + ++ +[source,log] +``` +include::manage:example$continuous-backup.log[tag=get-backup-info] +``` + ++ +The result shows that you can restore to a point in time between June 6th at 14:57 GMT and June 23rd at 17:55 GMT. + +. Use the `cbcontbk restore` command to restore the bucket. +The following command restores `travel-sample` to the state it was in at June 8th, 2026 at 19:54:10 GMT. + ++ +[source,bash] +``` +include::manage:example$continuous-backup.sh[tag=restore-bucket] +``` ++ +The output from this command looks like this: + ++ +[source,log] +``` +include::manage:example$continuous-backup.log[tag=restore-output] +``` + ++ +You can see that PITR restores a traditional full backup and possibly multiple incremental backups. +Then it replays mutations from the continuous backup until it reaches the selected point in time. + +. After you have finished the PITR, start continuous backup again. + ++ +[source,bash] +``` +couchbase-cli bucket-edit --cluster couchbase://localhost \ + --username $COUCHBASE_USERNAME --password $COUCHBASE_PASSWORD \ + --bucket travel-sample \ + --continuous-backup-enabled 1 +``` diff --git a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc index c0b2746a49..15af3b1ae1 100644 --- a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc @@ -37,26 +37,14 @@ The following example gets information about the continuous backup location stor [source,bash] ``` -cbcontbk info -l /shared/continuous-backup/ +include::manage:example$continuous-backup.sh[tag=get-backup-info] ``` The following example shows the output of the previous command for a location backing up the `travel-sample` bucket. -[source,bash] +[source,log] ``` -| Buckets -| ------- -| -| * Bucket -| ------ -| Name | UUID | -| travel-sample | b5de13bdc656985b0a41dd3d832c9be6 | -| -| Range -| ----- -| Start | End | -| 2026-06-05T14:57:18Z | 2026-06-05T17:55:22Z | -| +include::manage:example$continuous-backup.log[tag=get-backup-info] ``` The timestamps under the Range heading in the output show you the earliest and latest times you can restore the bucket to using point in time recovery (PITR). @@ -70,5 +58,5 @@ These metrics all start with the `contbk_` (continuous backup) prefix. // FIXME: link to metrics whenever they show up in the metrics_metadata file in the server build.. They aren't there as of build #2395 -For more information about monitoring Couchbase Server using metrics, see xref:current:manage/monitor/set-up-prometheus-for-monitoring.adoc[]. +For more information about monitoring Couchbase Server using metrics, see xref:manage:monitor/set-up-prometheus-for-monitoring.adoc[]. From 31efbb98b06dc2c485b6a4082f5697c985fd7a58 Mon Sep 17 00:00:00 2001 From: Gary Gray Date: Wed, 1 Jul 2026 15:41:07 -0400 Subject: [PATCH 06/28] Added the port # for cbcontbk to the list of ports and processes in the install section. --- modules/install/pages/install-ports.adoc | 12 ++- modules/install/pages/server-processes.adoc | 95 +++++++++++---------- 2 files changed, 60 insertions(+), 47 deletions(-) diff --git a/modules/install/pages/install-ports.adoc b/modules/install/pages/install-ports.adoc index c13a88f9bc..65d142d577 100644 --- a/modules/install/pages/install-ports.adoc +++ b/modules/install/pages/install-ports.adoc @@ -70,7 +70,7 @@ The following table lists all port numbers, grouped by category of communication | Communication Path | Default Ports | _Node-local only_ -| *Unencrypted*: 9119, 9998, 11213, 21200, 21300 +| *Unencrypted*: 9119, 9125, 9998, 11213, 21200, 21300 *Encrypted*: 21250 {fn-encrypted-traffic-port}, 21350 {fn-encrypted-communication-port} @@ -99,7 +99,7 @@ a| *Unencrypted*: 8091-8096, 9102, 11210 [NOTE] ==== `cbbackupmgr`, the backup client, connects to the Couchbase Server using the ports listed above. -You can find detailed information about the server ports in the xref:detailed-port-description[Detailed Port Description]. +You can find detailed information about the server ports in the <>. Below is a summary of the services cbbackupmgr is accessing via the ports. [horizontal] @@ -351,6 +351,14 @@ The following table contains a detailed description of each port used by Couchba | No | No +| `cbcontbk` +| 9125 +| Continuous backup +| No +| No +| No + + | `fts_grpc_port` / `fts_grpc_ssl_port` | 9130 / 19130 a| Search Service gRPC port used for xref:learn:services-and-indexes/services/search-service.adoc[scatter-gather] operations between FTS nodes diff --git a/modules/install/pages/server-processes.adoc b/modules/install/pages/server-processes.adoc index f477045a98..8f9f64c159 100644 --- a/modules/install/pages/server-processes.adoc +++ b/modules/install/pages/server-processes.adoc @@ -26,121 +26,126 @@ The following table lists the Couchbase processes that run on Linux platforms. | Process | Description | Service | Path +| `cbcontbk` +| The continuous backup agent. +| Backup +| `/opt/couchbase/bin` + | `cbft` | Couchbase Full-Text Search (FTS) service | Search -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `cbq-engine` | Couchbase Query service | Query -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `goport` (5 copies) | Process that acts as a bridge between `ns_server` (Erlang) and the other server components (`cbq- engine`, `cbft`, etc.) which are written in Go | Query -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `gosecrets` | Service that is used to encrypt the cluster configuration stored on disk | Data -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `goxdcr` | Cross Data Center Replication (XDCR) - replicates data from one cluster to another | Data -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `indexer` | Index service | Index -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `memcached` | Data service responsible for storing user data | Data -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `godu` (2 copies) | Utility in Go to get disk usage stats | Data -| _/opt/couchbase/bin/priv/_ +| `/opt/couchbase/bin/priv/` | `projector` | Extracts secondary key from documents | Data -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `saslauthd-port` | Erlang port process (wrapper) used to talk to the `saslauthd` daemon for authentication purposes | Data -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `beam.smp` (3 copies) | Couchbase cluster manager run as Erlang virtual machines - `babysitter`, `ns_server`, and `ns_couchdb` | Data -| _/opt/couchbase/lib/erlang/erts-9.3.3.9/bin/_ +| `/opt/couchbase/lib/erlang/erts-9.3.3.9/bin/` | `epmd` | Erlang-specific process which acts as a name server for Erlang distribution | Data -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `cpu_sup` (2 copies) | Erlang-specific process used to collect CPU: 1 for `ns_server` VM and 1 for `ns_couchdb` VM | Data -| _/opt/couchbase/lib/erlang/lib/os_mon-2.2.14/priv/bin/_ +| `/opt/couchbase/lib/erlang/lib/os_mon-2.2.14/priv/bin/` | `memsup` (2 copies) | Erlang-specific process used to collect memory usage: 1 for `ns_server` VM and 1 for `ns_couchdb` VM | Data -| _/opt/couchbase/lib/erlang/lib/os_mon-2.2.14/priv/bin/_ +| `/opt/couchbase/lib/erlang/lib/os_mon-2.2.14/priv/bin/` | `inet_gethost` (2 copies) | Built-in Erlang port process that is used to perform name service lookup | Data -| _/opt/couchbase/lib/erlang/erts-5.10.4.0.0.1/bin/_ +| `/opt/couchbase/lib/erlang/erts-5.10.4.0.0.1/bin/` | `portsigar` | Open source tool sigar that is used to collect system information | Data -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `sh -s disksup` (2 copies) | Erlang-specific process that is used to supervise the available disk space: 1 for `ns_server` VM and 1 for `ns_couchdb` VM | Data -| _/opt/couchbase/lib/erlang/lib/os_mon-2.2.14/ebin/_ +| `/opt/couchbase/lib/erlang/lib/os_mon-2.2.14/ebin/` | `sh -s ns_disksup` | Wrapper for `disksup` which also collects information about mounted drives | Data -| _/opt/couchbase/lib/ns_server/erlang/lib/ns_server/ebin/_ +| `/opt/couchbase/lib/ns_server/erlang/lib/ns_server/ebin/` | `cbcollect_info` | Utility used to collect Couchbase server logs (will be seen only during log collection) | Data -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `eventing-producer` (1 copy) | Eventing supervisor service (one instance per node) | Eventing -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `eventing-consumer` (n copies) | Eventing worker (multiple instances per node). Instance count is configured in UI. | Eventing -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` | `java` (Analytics Driver) | JVM running the Analytics NC and CC | Analytics -| _/opt/couchbase/lib/cbas/runtime/bin_ +| `/opt/couchbase/lib/cbas/runtime/bin` | `cbas` | Go-wrapper that communicates with `ns_server` and manages the lifecycle of the Analytics Driver | Analytics -| _/opt/couchbase/bin/_ +| `/opt/couchbase/bin/` |=== == Windows @@ -156,112 +161,112 @@ The following table lists the Couchbase processes that run on the Windows platfo | `backup.exe` | Backup application for Couchbase data | Backup -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `cbas.exe` | Go-wrapper that communicates with `ns_server` and manages the lifecycle of the Analytics Driver | Analytics -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `cbcollect_info.exe` | Utility used to collect Couchbase server logs (will be seen only during log collection) | Data -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `cbft.exe` | Couchbase Full-Text Search (FTS) service | Search -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `cbq-engine.exe` | Couchbase Query service | Query -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `epmd.exe` | Erlang-specific process which acts as a name server for Erlang distribution | Data -| _C:\Program Files\Couchbase\Server\erts-x.x.x.x\bin_ +| `C:\Program Files\Couchbase\Server\erts-x.x.x.x\bin` | `erl.exe` | Erlang process used by the name server. | Data -| _C:\Program Files\Couchbase\Server\erts-x.x.x.x\bin_ +| `C:\Program Files\Couchbase\Server\erts-x.x.x.x\bin` | `erlsrv.exe` | Used to start the Erlang emulator as a Windows process. | Data -| _C:\Program Files\Couchbase\Server\erts-x.x.x.x\bin_ +| `C:\Program Files\Couchbase\Server\erts-x.x.x.x\bin` | `eventing-consumer.exe` | Eventing worker (multiple instances per node). Instance count is configured in UI. | Eventing -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `eventing-producer.exe` | Eventing supervisor service (one instance per node) | Eventing -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `goport.exe` | Process that acts as a bridge between `ns_server` (Erlang) and the other server components (`cbq- engine.exe`, `cbft.exe`, etc.) | Query -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `gosecrets.exe` | Service that is used to encrypt the cluster configuration stored on disk | Data -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `goxdcr.exe` | Cross Data Center Replication (XDCR) - replicates data from one cluster to another | Data -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `indexer.exe` | Index service | Index -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `godu.exe` | Utility in Go to get disk usage stats | Data -| _C:\Program Files\Couchbase\Server\bin\priv_ +| `C:\Program Files\Couchbase\Server\bin\priv` | `inet_gethost.exe` | Built-in Erlang port process that is used to perform name service lookup | Data -| _C:\Program Files\Couchbase\Server\erts-x.x.x.x\bin_ +| `C:\Program Files\Couchbase\Server\erts-x.x.x.x\bin` | `java.exe` (Analytics Driver) | JVM running the Analytics NC and CC | Analytics -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `memcached.exe` | Data service responsible for storing user data | Data -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `projector.exe` | Extracts secondary key from documents | Data -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `prometheus.exe` | Engine used Couchbase for creating metrics. | Data -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `saslauthd-port.exe` | Erlang port process (wrapper) used to talk to the `saslauthd` daemon for authentication purposes | Data -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` | `sigar_port.exe` | Open source tool sigar that is used to collect system information | Data -| _C:\Program Files\Couchbase\Server\bin_ +| `C:\Program Files\Couchbase\Server\bin` |=== From 5eec3ce91bd844346343b43a596d17e38ee40454 Mon Sep 17 00:00:00 2001 From: Gary Gray Date: Wed, 1 Jul 2026 16:03:10 -0400 Subject: [PATCH 07/28] Added link to introduction. --- modules/introduction/partials/new-features-81.adoc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/modules/introduction/partials/new-features-81.adoc b/modules/introduction/partials/new-features-81.adoc index 4b549fe7fd..1141494f4b 100644 --- a/modules/introduction/partials/new-features-81.adoc +++ b/modules/introduction/partials/new-features-81.adoc @@ -67,6 +67,7 @@ TBD. Couchbase Server 8.1 introduces several new features for the xref:backup:backup.adoc[Backup Service]. * The new continuous backup feature supplements traditional periodic backups by frequently backing up changes to Magma buckets. -This backup can limit the loss of data updates that occur between full and incremental backups. +This backup can limit the loss of data updates that occur between full and incremental backups. In addition to backup up data, it also backs up timestamps of when the data was updated. These timestamps let you perform Point-In-Time Recovery (PITR) to restore the Magma bucket's data to the state it was in at a specific moment. +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for more information. From a99d78189f6a19c47c969ca8ffb2fd8ead1ee167 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:40:05 -0400 Subject: [PATCH 08/28] Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../pages/services-and-indexes/services/backup-service.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/learn/pages/services-and-indexes/services/backup-service.adoc b/modules/learn/pages/services-and-indexes/services/backup-service.adoc index 1f89e97778..87563a3be7 100644 --- a/modules/learn/pages/services-and-indexes/services/backup-service.adoc +++ b/modules/learn/pages/services-and-indexes/services/backup-service.adoc @@ -42,7 +42,7 @@ In addition to the periodic backups provided by the Backup Service, you can also This backup can limit the loss of data updates that occur between full and incremental backups. It also records the timestamps of when data was mutated. These timestamps let you perform Point-In-Time Recovery (PITR) to restore the Magma bucket's data to the state it was in at a specific moment. -See xref:learn:services/continuous-backup.adoc[] for more information about using continuous backup. +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for more information about using continuous backup. [#backup-service-architecture] == Backup Service Architecture From 987febd2b8a739ba68b941b5f1ad677feb6c56ec Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:40:53 -0400 Subject: [PATCH 09/28] Fixing anchor link Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/manage-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index 0841bf2d6b..20b0bccdca 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -11,7 +11,7 @@ See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an ove Before configuring continuous backup, your cluster must meet the following requirements: -* Your Couchbase Server account must have the xref:learn:security/roles.adoc#backup-full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. +* Your Couchbase Server account must have the xref:learn:security/roles.adoc#full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. * It must have 1 or more Magma buckets. Continuous backup relies on Magma's change history feature to back up individual mutations. From ffde6f3d4b1419dbc0413f51627a5d5b15ad67ca Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:42:20 -0400 Subject: [PATCH 10/28] Fixing link Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/manage-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index 20b0bccdca..b9cd90b17c 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -24,7 +24,7 @@ See xref:install:synchronize-clocks-using-ntp.adoc[] for more information. * You must configure scheduled periodic backups using either the Backup Service or `cbbackupmgr`. Point in Time Recovery (PITR) uses the full and incremental backups taken just before the point in time you're restoring to. It restores these backups and then uses the data stored in the continuous backup to fill the gap between the previous intermittent backup and the point in time you're recovering to. -See xref:manage-backup-and-restore.adoc[] to learn how to configure intermittent backups. +See xref:manage:manage-backup-and-restore/manage-backup-and-restore.adoc[] to learn how to configure intermittent backups. * You must have a shared location where continuous backup can store its backup data. All node in the cluster must be able to reach this location. From e811a87f1156be59a7945e92b1904c1de158f8c7 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:43:40 -0400 Subject: [PATCH 11/28] Typo fix and fixing broken link Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- modules/learn/pages/data/change-history.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/learn/pages/data/change-history.adoc b/modules/learn/pages/data/change-history.adoc index 003a3b423b..ec5cfceab3 100644 --- a/modules/learn/pages/data/change-history.adoc +++ b/modules/learn/pages/data/change-history.adoc @@ -49,10 +49,10 @@ See xref:rest-api:rest-bucket-create.adoc[Creating and Editing Buckets]. * The CLI, using `couchbase-cli bucket-create` (to create a bucket) or `couchbase-cli bucket-edit` (to edit a bucket); specifying one or both of the parameters `history-retention-bytes` and `history-retention-seconds`. See xref:cli:cbcli/couchbase-cli-bucket-create.adoc[bucket-create] and xref:cli:cbcli/couchbase-cli-bucket-edit.adoc[bucket-edit]. -IMPORTANT: You must enable change history on any bucket you want to back up using continuous backup on. +IMPORTANT: You must enable change history on any bucket you want to back up using continuous backup. Once you enable continuous backup, you cannot turn off change history for the bucket unless you turn off continuous backup first. -Using collection-level overrides of change history in a bucket where you have enabled continuous backup us unsupported. -See xref:learn:services/continuous-backup.adoc[] for more information. +Using collection-level overrides of change history in a bucket where you have enabled continuous backup is unsupported. +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for more information. [#default-collection-setting] === Default Collection-Setting From 19bfd14052b3da66b93187cb7dbc692035602df0 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:44:34 -0400 Subject: [PATCH 12/28] Fixing incorrect anchor Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/monitor-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc index 15af3b1ae1..7bb58bc370 100644 --- a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc @@ -9,7 +9,7 @@ See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an ove == Prerequisites -* Your Couchbase Server account must have the xref:learn:security/roles.adoc#backup-full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. +* Your Couchbase Server account must have the xref:learn:security/roles.adoc#full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. * You must have a Magma bucket with continuous backup enabled. See xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc[] for the steps to configure continuous backup for a Magma bucket. From f76f3fd839426d96409a9cf870e65d313d1cd731 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:45:07 -0400 Subject: [PATCH 13/28] Typo fix Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- modules/introduction/partials/new-features-81.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/introduction/partials/new-features-81.adoc b/modules/introduction/partials/new-features-81.adoc index 1141494f4b..9cc76fc73b 100644 --- a/modules/introduction/partials/new-features-81.adoc +++ b/modules/introduction/partials/new-features-81.adoc @@ -68,6 +68,6 @@ Couchbase Server 8.1 introduces several new features for the xref:backup:backup. * The new continuous backup feature supplements traditional periodic backups by frequently backing up changes to Magma buckets. This backup can limit the loss of data updates that occur between full and incremental backups. -In addition to backup up data, it also backs up timestamps of when the data was updated. +In addition to backing up data, it also backs up timestamps of when the data was updated. These timestamps let you perform Point-In-Time Recovery (PITR) to restore the Magma bucket's data to the state it was in at a specific moment. See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for more information. From b489b9bc1f79a56d7294a475930a5f5155efe71e Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:46:07 -0400 Subject: [PATCH 14/28] Removing stray step Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/manage-continuous-backup.adoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index b9cd90b17c..538158300d 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -166,8 +166,7 @@ You can configure continuous backup using the Couchbase Server Web Console, the . If creating a new bucket, click *Add Bucket*. Otherwise, expand an existing bucket and click *Edit*. . Click *Advanced Bucket Settings*. -. Under -. Under Continuous Backup, select *Enable*. +. Under *Continuous Backup*, select *Enable*. . Enter the location to store the continuous backup data. This is either: * An absolute path to the mount point of a shared network storage location such as an NFS share. From 0a6c053ffd92d4a0c566a84a40b2eee2ce7dd2de Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:46:32 -0400 Subject: [PATCH 15/28] Typo fix Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../pages/services-and-indexes/services/continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc index 5e496207c8..bbba4d541b 100644 --- a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc +++ b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc @@ -135,7 +135,7 @@ However, they can only restore the bucket to the state it was in when the backup You cannot use them to restore the bucket to an arbitrary point in time. When choosing the retention period, you must balance between the cost of storing the backup data and the flexibility of restoring your bucket to an earlier time. -If you choose cloud storage for your continuous backup location, you pay data storage fees based on the amounrt of data you store. +If you choose cloud storage for your continuous backup location, you pay data storage fees based on the amount of data you store. These fees increase the longer you set the retention period. == How PITR Works From f038fb0a091e3ce1bd4a72db37183486a969da12 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:47:16 -0400 Subject: [PATCH 16/28] Fixing accidental Markdown Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/manage-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index 538158300d..a75ce7aff0 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -260,7 +260,7 @@ couchbase-cli bucket-edit --cluster couchbase://node1.example.com \ See the documentation for the `couchbase-cli` tool's xref:cli:cbcli/couchbase-cli-bucket-create.adoc[] and xref:cli:cbcli/couchbase-cli-bucket-edit.adoc[] commands for more information about creating and editing buckets using the command line. [#stop-continuous-backup] -## Stop Continuous Backup +== Stop Continuous Backup Once enabled, you can stop continuous backup for a bucket. You must must continuous backups before you do a PITR to prevent a backup from occurring during the restore. From 5bda019545a01e77a6767aba69cb76fc6265d8ce Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:48:35 -0400 Subject: [PATCH 17/28] Remove accidental Markdown Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc index 6b5d672646..08c27dbcb1 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -61,7 +61,7 @@ See xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc#stop-con NOTE: You do not need to stop traditional periodic backups or XDCR for the bucket when performing PITR. -## Restore to a Point in Time +== Restore to a Point in Time You use the `cbcontbk` command line tool to restore a bucket backed up using continuous backup to point in time. From c052a8acbc8553b601ac6b4f8b3ed076cb79fc20 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:49:10 -0400 Subject: [PATCH 18/28] Remove duplicate word Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/manage-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index a75ce7aff0..0d6d059203 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -263,7 +263,7 @@ See the documentation for the `couchbase-cli` tool's xref:cli:cbcli/couchbase-cl == Stop Continuous Backup Once enabled, you can stop continuous backup for a bucket. -You must must continuous backups before you do a PITR to prevent a backup from occurring during the restore. +You must stop continuous backup before you do a PITR to prevent a backup from occurring during the restore. You may also want to stop it to preserve the PITR recovery window that's currently in the continuous backup location. You can turn off continuous backup using the Couchbase Server Web Console, REST API, or command line: From b25f4ea16144f4edbc9ff715fa3570ce202187e4 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:49:46 -0400 Subject: [PATCH 19/28] Fixing typo Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/manage-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index 0d6d059203..d8cbe1c0ae 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -284,7 +284,7 @@ Make a POST call to the `/pools/default/buckets/` endpoint and set For example, to turn off continuous backup for the `travel-sample` bucket, use this command: + -[souce,bash] +[source,bash] ``` curl -X POST localhost:8091/pools/default/buckets/travel-sample \ -u $COUCHBASE_USERNAME:$COUCHBASE_PASSWORD \ From d23144a191d0ce65bbdade343525008306c2b296 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:50:29 -0400 Subject: [PATCH 20/28] Fixing command name Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/manage-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index d8cbe1c0ae..d48a3e3fc7 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -293,7 +293,7 @@ curl -X POST localhost:8091/pools/default/buckets/travel-sample \ Using the Command Line Interface:: -Use the `couchbase-cli` tools' `edit-bucket` command with the argument `--continuous-backup-enabled 0`: +Use the `couchbase-cli` tools' `bucket-edit` command with the argument `--continuous-backup-enabled 0`: [source.bash] ``` From fe8d8f4a2ff6247bc2000bb3ba0437663e444e49 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:51:05 -0400 Subject: [PATCH 21/28] Fixing typo Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/manage-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index d48a3e3fc7..fca2a778de 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -295,7 +295,7 @@ Using the Command Line Interface:: Use the `couchbase-cli` tools' `bucket-edit` command with the argument `--continuous-backup-enabled 0`: -[source.bash] +[source,bash] ``` couchbase-cli bucket-edit --cluster couchbase://node1.example.com \ --username $COUCHBASE_USERNAME --password $COUCHBASE_PASSWORD \ From f00b6113bd5e48d68d06b6841f445442bb9a6684 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:51:38 -0400 Subject: [PATCH 22/28] Yet more Markdown Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc index 08c27dbcb1..56b2443da4 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -7,7 +7,7 @@ {description} See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an overview of continuous backup and point in time recovery. -## Prerequisites +== Prerequisites * Your Couchbase Server account must have the xref:learn:security/roles.adoc#backup-full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. From c62fb79382d46f49c445bd304dc78b909b04c7f4 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:52:12 -0400 Subject: [PATCH 23/28] Fixing anchor Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc index 56b2443da4..2db3e7b4b7 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -9,7 +9,7 @@ See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an ove == Prerequisites -* Your Couchbase Server account must have the xref:learn:security/roles.adoc#backup-full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. +* Your Couchbase Server account must have the xref:learn:security/roles.adoc#full-admin[Full Admin] or xref:learn:security/roles.adoc#backup-full-admin[Backup Full Admin] role. * You must have a Magma bucket configured with continuous backup. See xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc[] for the steps to configure continuous backup for a Magma bucket. From 45e430063d5841b51c139eedf1eb18560a570a26 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:52:37 -0400 Subject: [PATCH 24/28] Fixing typo Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc index 2db3e7b4b7..eb2b345e0f 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -18,7 +18,7 @@ See xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc[] for th This means continuous backup must have been active for a bit longer than its continuous backup interval. * You must have a traditional periodic backups for the bucket you are restoring. -Continuous backup restores the most recent full backup taken before the pont in time you are restoring to. +Continuous backup restores the most recent full backup taken before the point in time you are restoring to. It then restores any incremental backups taken between the full backup and the point in time you chose. It uses the data in the continuous backup location to fill the gap between the last traditional backup it restored and the target point in time. From fcd8afff95b42a4be67b72dde267f844545750c8 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:53:43 -0400 Subject: [PATCH 25/28] Add missing word Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc index eb2b345e0f..6ccc298f29 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -77,7 +77,7 @@ This is either the absolute path of the NFS mount point, or the URI of the cloud * `-c` is the URL for a node in the cluster running the backup service. In addition, you must supply credentials the Backup Service can use to authenticate with the continuous backup location and the traditional backup repository if they're stored in the cloud. -You have encrypted backups, you must also supply credentials to decrypt them. +If you have encrypted backups, you must also supply credentials to decrypt them. See the documentation for `cbcontbk` for details. // FIXME: add link to `cbcontbk` docs when they are available in the repo. From ea725c3ddb96c699bd88f50b72eea91c941b951a Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:54:19 -0400 Subject: [PATCH 26/28] Fixing typo Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc index 6ccc298f29..1ce418bd58 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -123,7 +123,7 @@ couchbase-cli bucket-edit --cluster couchbase://localhost \ --enable-flush 1 ``` -After finishing the PITR, consider tunring off flushing the bucket again to prevent accidental data loss. +After finishing the PITR, consider turning off flushing the bucket again to prevent accidental data loss. ==== . Before performing the restore, you should verify the point in time you want to restore to is available in the continuous backup location. From b631d1ba45f02a9a6f3d1c5f60b30c64d724cd96 Mon Sep 17 00:00:00 2001 From: Gary Gray <137797428+ggray-cb@users.noreply.github.com> Date: Thu, 2 Jul 2026 09:54:52 -0400 Subject: [PATCH 27/28] Yet more markdown Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../manage-backup-and-restore/monitor-continuous-backup.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc index 7bb58bc370..64b9aba2c2 100644 --- a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc @@ -50,7 +50,7 @@ include::manage:example$continuous-backup.log[tag=get-backup-info] The timestamps under the Range heading in the output show you the earliest and latest times you can restore the bucket to using point in time recovery (PITR). See xref:manage:manage-backup-and-restore/manage-pitr.adoc[] for more information about performing a PITR. -## Continuous Backup Metrics +== Continuous Backup Metrics Continuous backup exposes several metrics that let you monitor its status. You can use these metrics to monitor its status in tools such as Prometheus. From 05cb3a910eace55ebcfa93bd65f9bd78d4346ead Mon Sep 17 00:00:00 2001 From: Gary Gray Date: Thu, 2 Jul 2026 10:28:45 -0400 Subject: [PATCH 28/28] Standardizing terminology use. Fixing several incomplete sentences. --- .../partials/new-features-81.adoc | 2 +- .../services/continuous-backup.adoc | 4 ++-- .../manage-continuous-backup.adoc | 10 ++++---- .../manage-pitr.adoc | 24 +++++++++---------- .../monitor-continuous-backup.adoc | 4 ++-- 5 files changed, 22 insertions(+), 22 deletions(-) diff --git a/modules/introduction/partials/new-features-81.adoc b/modules/introduction/partials/new-features-81.adoc index 9cc76fc73b..ff1ae98cee 100644 --- a/modules/introduction/partials/new-features-81.adoc +++ b/modules/introduction/partials/new-features-81.adoc @@ -69,5 +69,5 @@ Couchbase Server 8.1 introduces several new features for the xref:backup:backup. * The new continuous backup feature supplements traditional periodic backups by frequently backing up changes to Magma buckets. This backup can limit the loss of data updates that occur between full and incremental backups. In addition to backing up data, it also backs up timestamps of when the data was updated. -These timestamps let you perform Point-In-Time Recovery (PITR) to restore the Magma bucket's data to the state it was in at a specific moment. +These timestamps let you perform point-in-time recovery (PITR) to restore the Magma bucket's data to the state it was in at a specific moment. See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for more information. diff --git a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc index bbba4d541b..898210c490 100644 --- a/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc +++ b/modules/learn/pages/services-and-indexes/services/continuous-backup.adoc @@ -1,4 +1,4 @@ -= Continuous Backup & Point in Time Recovery += Continuous Backup & Point-in-Time Recovery :description: pass:q[Continuous backup frequently backs up mutations to Magma buckets and records timestamps to enable Point-In-Time Recovery (PITR).] :enterprise-only: :toclevels: 3 @@ -41,7 +41,7 @@ For example, the following diagram shows a continuous backup that's configured t | Midnight | 2:00 A.M. .... -== Point in Time Recovery +== Point-in-Time Recovery With periodic backups, you can only restore a bucket to the state it was in when it was backed up. For example, consider the backups shown in the Periodic Backup diagram. diff --git a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc index fca2a778de..f357783394 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-continuous-backup.adoc @@ -22,7 +22,7 @@ Couchstore buckets can still be backed up and restored using the traditional ful See xref:install:synchronize-clocks-using-ntp.adoc[] for more information. * You must configure scheduled periodic backups using either the Backup Service or `cbbackupmgr`. -Point in Time Recovery (PITR) uses the full and incremental backups taken just before the point in time you're restoring to. +Point-in-time recovery (PITR) uses the full and incremental backups taken just before the point in time you're restoring to. It restores these backups and then uses the data stored in the continuous backup to fill the gap between the previous intermittent backup and the point in time you're recovering to. See xref:manage:manage-backup-and-restore/manage-backup-and-restore.adoc[] to learn how to configure intermittent backups. @@ -199,8 +199,8 @@ You must grant the Backup Service access to this credential. * `continuousBackupInterval`: How frequently, in minutes, the Backup Service copies data to the continuous backup location. When using a cloud-based storage location, lower settings for this value result in higher per-access costs. * `continuousBackupRetentionPeriod`: the number of hours the Backup Service keeps the continuous backup data before purging it. -This value sets how far back in time you can use Point in Time Recovery (PITR). -* If you have enabled encryption at rest for the bucket, you must supply one of the following: +This value sets how far back in time you can use point-in-time recovery (PITR). +* If you have enabled encryption at rest for the bucket, you must supply 1 of the following: ** `continuousBackupKmKeyUrl`: The URI for the KMS key the Backup Service uses to manage the encryption key it uses to encrypt data encryption keys. This URI must start with `awskms`, `azurekeyvalue`, or `gcpkms`. ** `continuousBackupKmCredId`: the name of a credential in the Couchbase Server credential store that grants the Backup Service access to a KMS to manage its encryption keys. @@ -235,8 +235,8 @@ You must also grant the Backup Service access to this credential. * `--continuous-backup-interval`: How frequently in minutes then Backup Service copies data to the continuous backup location. When using a cloud-based storage location, lower settings for this value result in higher per-access costs. * `--continuous-backup-retention-period`: the number of hours the Backup Service keeps the continuous backup data before purging it. -This value sets how far back in time you can use Point in Time Recovery (PITR). -* If you have enabled encryption at rest for the bucket, you must supply one of the following: +This value sets how far back in time you can use point-in-time recovery (PITR). +* If you have enabled encryption at rest for the bucket, you must supply 1 of the following: ** `--continuous-backup-km-key-url`: The URI for the KMS key the Backup Service uses to manage the encryption key it uses to encrypt data encryption keys. This URI must start with `awskms`, `azurekeyvalue`, or `gcpkms`. ** `--continuous-backup-km-cred=id`: the name of a credential in the Couchbase Server credential store that grants the Backup Service access to a KMS to manage its encryption keys. diff --git a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc index 1ce418bd58..0e43cb7e1a 100644 --- a/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc +++ b/modules/manage/pages/manage-backup-and-restore/manage-pitr.adoc @@ -1,11 +1,11 @@ -= Manage Point in Time Recovery (PITR) -:description: pass:q[Point in time recovery (PITR) lets you restore a bucket to the state it was in at a specific time.] += Manage Point-in-Time Recovery (PITR) +:description: pass:q[Point-in-time recovery lets you restore a bucket to the state it was in at a specific time.] :enterprise-only: :toclevels: 3 [abstract] {description} -See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an overview of continuous backup and point in time recovery. +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an overview of continuous backup and point-in-time recovery. == Prerequisites @@ -17,8 +17,8 @@ See xref:manage:manage-backup-and-restore/manage-continuous-backup.adoc[] for th * Continuous backup must have made at least a single backup to the continuous backup location. This means continuous backup must have been active for a bit longer than its continuous backup interval. -* You must have a traditional periodic backups for the bucket you are restoring. -Continuous backup restores the most recent full backup taken before the point in time you are restoring to. +* You must have a traditional periodic backups for the bucket you're restoring. +Continuous backup restores the most recent full backup taken before the point in time you're restoring to. It then restores any incremental backups taken between the full backup and the point in time you chose. It uses the data in the continuous backup location to fill the gap between the last traditional backup it restored and the target point in time. @@ -32,9 +32,9 @@ If you need to restore your cluster to a point earlier than this time, you can o However, you cannot restore to a specific point in time with traditional backup. + -The latest time you can restore to is whenever the Backup Service last copied data to the continuous backup location. +The latest time you can restore to is whenever the continuous backup agent last copied data to the continuous backup location. This may be as far back in the past as the continuous backup iteration period you set when configuring continuous backup. -If you stopped continuous backup earlier than +If you stopped continuous backup, then you can only restore up to the moment you stopped it. + See xref:manage:manage-backup-and-restore/monitor-continuous-backup.adoc#get-cont-backup-info[Get Information About a Continuous Backup Location] to learn how to find the range of time backed up by a continuous backup location. @@ -69,14 +69,14 @@ When calling `cbcontbk`, you must supply the following arguments: * `--target` is the date and time you want to restore the bucket to in an https://www.rfc-editor.org/info/rfc3339/[RFC3339 timestamp^]. * `-u` and `-p` are the username and password for the full administrator. -* `--tmp-dir` a temporary directory the Backup Service can use when restoring data. +* `--tmp-dir` a temporary directory the `cbcontbk` can use when restoring data. * `-l` the continuous backup storage location. This is either the absolute path of the NFS mount point, or the URI of the cloud storage location. -* `-a` the path to the traditional backup directory or its . +* `-a` the filesystem path or S3 URI storing the traditional backup repository. * `-r` is the UUID for the repository containing the bucket's traditional backup. -* `-c` is the URL for a node in the cluster running the backup service. +* `-c` is the URL for a node in the cluster running the Backup Service. -In addition, you must supply credentials the Backup Service can use to authenticate with the continuous backup location and the traditional backup repository if they're stored in the cloud. +In addition, you must supply credentials `cbcontbk` can use to authenticate with the continuous backup location and the traditional backup repository if they're stored in the cloud. If you have encrypted backups, you must also supply credentials to decrypt them. See the documentation for `cbcontbk` for details. @@ -87,7 +87,7 @@ Also suppose you want to restore to the original bucket and want the bucket to b In that case, you can follow these steps to perform the PITR: . Stop continuous backup for the bucket. -Because you'll need to use the command line to run `cbcontbk` anyhow, this example uses command line on one of the nodes to stop continuous backup: +Because you'll need to use the command line to run `cbcontbk` anyhow, this example uses the command line on a node to stop continuous backup: + [source,bash] diff --git a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc index 64b9aba2c2..dab892a843 100644 --- a/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc +++ b/modules/manage/pages/manage-backup-and-restore/monitor-continuous-backup.adoc @@ -5,7 +5,7 @@ [abstract] {description} -See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an overview of continuous backup and point in time recovery. +See xref:learn:services-and-indexes/services/continuous-backup.adoc[] for an overview of continuous backup and point-in-time recovery. == Prerequisites @@ -47,7 +47,7 @@ The following example shows the output of the previous command for a location ba include::manage:example$continuous-backup.log[tag=get-backup-info] ``` -The timestamps under the Range heading in the output show you the earliest and latest times you can restore the bucket to using point in time recovery (PITR). +The timestamps under the Range heading in the output show you the earliest and latest times you can restore the bucket to using point-in-time recovery (PITR). See xref:manage:manage-backup-and-restore/manage-pitr.adoc[] for more information about performing a PITR. == Continuous Backup Metrics