v26.2 previews of faster restore, improved show backups; syntax updates/removals#23215
Conversation
✅ Deploy Preview for cockroachdb-interactivetutorials-docs canceled.
|
✅ Deploy Preview for cockroachdb-api-docs canceled.
|
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify project configuration. |
Files changed:
|
ecf873e to
ee64899
Compare
- Backup IDs with efficient querying (use_backups_with_ids session variable, NEWER THAN/OLDER THAN filtering) - Faster restore with WITH EXPERIMENTAL COPY option - Backup compactions for extended backup chains - Remove incremental_location option (breaking change) Co-Authored-By: roachdev-claude <roachdev-claude-bot@cockroachlabs.com>
8e091fe to
7a54c9f
Compare
This session variable is already in main via PR #23200 and should not appear in this PR's diff. Co-Authored-By: roachdev-claude <roachdev-claude-bot@cockroachlabs.com>
restore, improved show backups; syntax deprecations/removals [DOC-16710] [DOC-16709] [DOC-16503]restore, improved show backups; syntax deprecations/removals
- Remove broken references to deleted incremental_location section - Replace cluster settings anchor links with plain code text (backup.compaction.threshold, backup.index.read.enabled)
|
|
||
| ### Combine with faster restore | ||
|
|
||
| You can combine backup IDs with the `WITH EXPERIMENTAL COPY` option for maximum performance: |
kev-cao
left a comment
There was a problem hiding this comment.
Overall looks good to me! The only required changes right now are fixing the backup IDs to be proper backup IDs instead of timestamps, and removing the revision_start_time column when WITH REVISION START TIME isn't specified.
I went through some of our test backups and found this that you could use for our examples:
id | backup_time | revision_start_time
-------------------+------------------------+-------------------------
Wnfqrp0BAAD4tw8= | 2026-04-21 07:21:35+00 | 2026-04-21 07:20:22+00
clvprp0BAADQmww= | 2026-04-21 07:20:22+00 | 2026-04-21 07:16:26+00
osDlrp0B | 2026-04-21 07:16:26+00 | 1970-01-01 00:00:00+00
|
|
||
| The threshold is the backup chain length at which compaction triggers: | ||
| - `0`: Disabled (default) | ||
| - `4`: Compaction occurs when chain reaches length 4 (1 full + 3 incrementals) |
There was a problem hiding this comment.
I'm wondering if we should have stronger wording about setting it to 4. If a customer reads this, they may be tempted to start setting it to what they think would work for them. @msbutler what do you think?
There was a problem hiding this comment.
+1. At first glance this read to me that 4 is the minimum value but it can be set higher as desired. If we want to keep the recommended value at 4, that should be emphasized.
There was a problem hiding this comment.
@msbutler @kev-cao Do you want to just be explicit here and elsewhere that 'higher values are not recommended' and try to drop an earlier mention that this is a 'configurable' number, just to de-emphazie that point, without actually implying everywhere that it's not configurable? Maybe that's the balance?
LMK and I'll try to implement. Also wouldn't mind merging and iterating, if that is better, to help our team get things sorted for the release quickly.
There was a problem hiding this comment.
Yeah I think having an explicit statement is fine
Replace timestamp-based IDs with real backup IDs from engineer's sample data: - Wnfqrp0BAAD4tw8= (newest) - clvprp0BAADQmww= (middle) - osDlrp0B (oldest) Updated all SHOW BACKUPS and RESTORE examples in show-backup.md and restore.md to use proper backup ID format instead of timestamps like '2026-04-16T14:23:55.335570Z'. Co-Authored-By: roachdev-claude <roachdev-claude-bot@cockroachlabs.com>
This reverts commit 908ffe8.
@kev-cao FIxed! PTAL. I think all the necessary items are now resolved. |
restore, improved show backups; syntax deprecations/removalsrestore, improved show backups; syntax updates/removals
jhlodin
left a comment
There was a problem hiding this comment.
Left a few comments and suggestions
|
|
||
| The threshold is the backup chain length at which compaction triggers: | ||
| - `0`: Disabled (default) | ||
| - `4`: Compaction occurs when chain reaches length 4 (1 full + 3 incrementals) |
There was a problem hiding this comment.
+1. At first glance this read to me that 4 is the minimum value but it can be set higher as desired. If we want to keep the recommended value at 4, that should be emphasized.
|
|
||
| | Setting | Description | Default | | ||
| |---------|-------------|---------| | ||
| | `backup.compaction.threshold` | Backup chain length at which compaction triggers. `0` disables; minimum `4`. | `0` | |
There was a problem hiding this comment.
| | `backup.compaction.threshold` | Backup chain length at which compaction triggers. `0` disables; minimum `4`. | `0` | | |
| | `backup.compaction.threshold` | Backup chain length at which compaction triggers. `0` disables; minimum and recommended value of `4`. | `0` | |
There was a problem hiding this comment.
As a suggestion - see above discussion
There was a problem hiding this comment.
Same feedback applies to other files if eng determines this is the suggested approach
|
|
||
| ### Prerequisites | ||
|
|
||
| To run faster restores, [backup compactions]({% link {{ page.version.version }}/backup.md %}#backup-compactions) must be enabled on the backup you are restoring from. To enable compactions, set the `backup.compaction.threshold` cluster setting to `4` or higher before creating your backups. |
There was a problem hiding this comment.
This wording makes it sound like "faster restores" is a proper noun/feature name, rather than descriptive. Suggest "To optimize restore performance" as a more descriptive alternative
There was a problem hiding this comment.
@jhlodin Since this restore method is distinct, it’s likely to read like a feature name, even while we intentionally avoid fully treating it like one. Eng/PM aligned on “faster restores,” and I’d prefer to stick with that to avoid it being misread as just a faster version of the traditional approach, which it isn’t. The Preview status also helps signal that it’s something different.
This is a temporary phase anyway; it’ll eventually become the default (details TBD). For now, we clarify that it refers to restores using WITH EXPERIMENTAL COPY, though that specific syntax likely won’t always be required.
The only alternative I’ve considered is a more-specific “Faster restores using WITH EXPERIMENTAL COPY,” but it’s a bit clunky, so I leaned on context instead. Open to other ideas, but hopefully that context helps explain the tradeoffs and the choice thus far?
There was a problem hiding this comment.
Makes sense. If eng/PM aligned on the name already then I won't push back more now
|
|
||
| ### Prerequisites | ||
|
|
||
| To run faster restores, [backup compactions]({% link {{ page.version.version }}/backup.md %}#backup-compactions) must be enabled on the backup you are restoring from. To enable compactions, set the `backup.compaction.threshold` cluster setting to `4` or higher before creating your backups. |
There was a problem hiding this comment.
should we simply say; set the value to 4?
There was a problem hiding this comment.
Sorry I missed this before. Refined.
|
|
||
| | Setting | Description | Default | | ||
| |---------|-------------|---------| | ||
| | `backup.compaction.threshold` | Backup chain length at which compaction triggers. `0` disables. `4` is the only recommended value for compaction. | `0` | |
There was a problem hiding this comment.
we do need to keep backup.compaction.threshold cluster setting change doc, just not backup.index.read.enabled
There was a problem hiding this comment.
@msbutler I dropped the table because we thoroughly covered backup.compaction.threshold nearby with the same details, so the section/table no longer seemed necessary. WDYT?
There was a problem hiding this comment.
ah, then its fine to drop the table. ty!

Fixes DOC-16710 DOC-16503
Per plan