Serhiy Bzhezytskyy created SOLR-18403:
-----------------------------------------
Summary: bin/solr snapshot-export silently backs up the live
index instead of the named snapshot
Key: SOLR-18403
URL: https://issues.apache.org/jira/browse/SOLR-18403
Project: Solr
Issue Type: Bug
Components: Backup/Restore
Reporter: Serhiy Bzhezytskyy
SnapshotExportTool.java builds its backup request as:
CollectionAdminRequest.Backup backup = new
CollectionAdminRequest.Backup(collectionName, snapshotName);
backup.setCommitName(snapshotName);
but never calls .setIncremental(false). commitName is only read by the server's
non-incremental backup path (BackupCmd.copyIndexFiles()); since incremental
defaults to true, that path is never taken here, and commitName is silently
ignored.
Verified empirically against a real 2-node MiniSolrCloudCluster: indexed 5
docs, created a named snapshot, indexed 5 more docs (live index now 10), ran
the export, restored the result into a new collection -- restored collection
has 10 docs, not the snapshot's 5. The outgoing request confirms it:
...&commitName=probe-snap&incremental=true.... No error or warning is raised.
History, for context: the commitName-based export logic predates incremental
backups entirely (it worked correctly before SOLR-13608 existed, since there
was no competing default). SOLR-13608 introduced incremental defaulting to true
(2021); per that ticket's own discussion, non-incremental creation was
originally meant to be removed at the same time, but was kept for testing
purposes, and this specific interaction was never revisited. SOLR-17180 (2024)
ported the logic verbatim from the old snapshotscli.sh-backed SolrSnapshotsTool
into the new bin/solr snapshot-export, carrying the bug forward unchanged
rather than introducing it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
