SOLR-18358: remove the non-incremental (full-snapshot) backup path - #4808
Open
serhiy-bzhezytskyy wants to merge 2 commits into
Open
SOLR-18358: remove the non-incremental (full-snapshot) backup path#4808serhiy-bzhezytskyy wants to merge 2 commits into
serhiy-bzhezytskyy wants to merge 2 commits into
Conversation
Removes CollectionAdminRequest.Backup.setIncremental(boolean) and the incremental=false branch it controlled in BackupCmd, plus the orphaned commitName/snapshotName fields on Backup and the v2 REST request body (commitName was only read inside the deleted path). SnapShooter's own, separate commitName handling is untouched -- verified it has zero dependency on incremental, it's an independent BACKUPCORE capability. CoreAdminParams.COMMIT_NAME kept -- shared with the snapshot admin actions. Test fixture for the legacy-format rejection test now built by hand on disk instead of via the removed API.
epugh
reviewed
Aug 25, 2026
epugh
left a comment
Contributor
There was a problem hiding this comment.
I was expecting more changes in the Ref Guide, not jsut a not or two.. or more of an API to be deleted!
| Solr can still restore from backups that use this old format, but creating new backups of this format is not recommended and is officially deprecated. | ||
| See the `incremental` parameter below for more information. | ||
| Previous versions of Solr supported creating a different, non-incremental backup file format that lacked the incremental support described above. | ||
| That format can no longer be created, but Solr can still restore from backups that already use it. |
Contributor
There was a problem hiding this comment.
is this something we would want to keep long term? Or is it a temporary thing?
| Provided as a query parameter for v1 requests, or as a path segment for v2 requests. | ||
| + | ||
| For incremental backups, the backup name should be reused to add new backup points to the existing backup. For non-incremental backups (deprecated), this name is checked to ensure it doesn't already exist, and an error message is raised if it does. | ||
| The backup name should be reused to add new backup points to the existing backup. |
Contributor
There was a problem hiding this comment.
should this be rephrased as "The name of the backup to use"?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
https://issues.apache.org/jira/browse/SOLR-18358
Removes
CollectionAdminRequest.Backup.setIncremental(boolean)and theincremental=false("full snapshot") backup path inBackupCmd, plus thecommitName/snapshotNamefields onBackupand the v2 REST request body --commitNamewas only ever read inside the path being removed.SnapShooter's own, separatecommitNamehandling (the core-levelBACKUPCOREaction) is untouched -- checked, it has zero dependency onincremental, it's an independent capability outside this ticket's scope.CoreAdminParams.COMMIT_NAMEis kept, since it's shared with the snapshot admin actions (CREATESNAPSHOT/etc).BackupRestoreApiErrorConditionsTest's legacy-format-rejection test now builds its on-disk fixture by hand (can't create one via the removed API anymore); everything else is a straight collapse ofif (incremental)branches.Related, and in tension with this PR: #4807 (SOLR-18403) fixes
bin/solr snapshot-exportto correctly usecommitName+incremental=false-- the exact capability this PR removes. If both land, #4807's fix becomes moot. Flagging for whoever reviews either one; not resolving the sequencing here.AI-assisted (Claude Sonnet 5)