[Bug] Local backup snapshots are indexed only by label and can collide across databases

[wenzhenghu]

Search before asking

• I had searched in the issues and found no similar issues.

Version

• master
• branch-3.1

Whats Wrong?

Local backup snapshots are indexed in FE memory only by the bare snapshot label.

The current implementation keeps local snapshots in BackupHandler.localSnapshots as Map<String, BackupJob> and getSnapshot RPC also looks up the snapshot only by request.label_name.

As a result, local snapshots from different databases can collide when they use the same label:

• creating a later local snapshot with the same label can overwrite the previous one in FE memory;
• getSnapshot may return the snapshot from another database;
• eviction or removal may also affect the wrong snapshot entry.

This is not just a path naming issue. Although local staging directories include label + "__" + createTime and remote job-info files include timestamps, the in-

Seakup key is still only the bare label.

What You Expected?

Local backup snapshots should be uniquely identified by database scope, for example (dbId, label) or an equivalent key that matches the SQL semantics of db.label.

getSnapshot should use the database dimension from the request when resolving a local snapshot, instead of looking up by bare label only.

How to Reproduce?

1. Create database db1 and database db2.
2. Create one local backup snapshot in db1 with label same_label.
3. Create another local backup snapshot in db2 with the same label same_label.
4. Call the local snapshot retrieval path for db1.same_label and db2.same_label.

Expected:
Each database resolves its own local snapshot.

Actual:
The FE local snapshot map is keyed only by label, so one snapshot can overwrite the other and the lookup can resolve the wrong snapshot.

Anything Else?

Relevant code paths:

• fe/fe-core/src/main/java/org/apache/doris/backup/BackupHandler.java
• fe/fe-core/src/main/java/org/apache/doris/service/FrontendServiceImpl.java
• fe/fe-core/src/main/java/org/apache/doris/analysis/AbstractBackupStmt.java
• fe/fe-core/src/main/java/org/apache/doris/analysis/LabelName.java

This issue is intentionally tracked separately from the recent staging-directory cleanup changes, because it is a distinct correctness problem and should be fixed in a focused PR.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this projects Code of Conduct

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_100ef8e9b801
This content is generated by AI for reference only.

I checked the current upstream/master and upstream/branch-3.1 FE backup paths. The report looks valid and is a real local-snapshot correctness issue, not only a local path naming issue.

Code evidence:

• BackupHandler.localSnapshots is a single FE-memory Map<String, BackupJob>, and both master and branch-3.1 key it only by the bare label.
• A completed local backup calls addSnapshot(label, this) from the BackupJob finish path, so a later completed local backup with the same label can replace the earlier map entry even if it belongs to another database.
• FrontendServiceImpl.getSnapshotImpl() requires request.db and uses it for the privilege check, but then resolves the local snapshot with only request.label_name via Env.getCurrentEnv().getBackupHandler().getSnapshot(label).
• The removal/eviction path is also label-only: when old local backup jobs are removed from a per-database history list, BackupHandler.removeSnapshot(label) removes the global map entry for that bare label.

So the expected failure mode is plausible from the current code: two databases can have local backups with the same label at SQL scope, but the FE local snapshot cache cannot distinguish them. This can cause wrong snapshot retrieval, overwrite of the previous local snapshot entry, or removal of another database's snapshot entry.

Suggested fix direction:

• Change the local snapshot key from label to a database-scoped key, preferably (dbId, label) because BackupJob already stores dbId and request.db can be resolved to a database id before lookup.
• Update addSnapshot, removeSnapshot, and getSnapshot together, including the finish path, image/replay reconstruction path, and history eviction path. Keeping only getSnapshot scoped is not enough if insert/remove remain label-only.
• Keep this scoped to the local in-memory snapshot map; remote repository snapshot naming and timestamped local staging directories are separate mechanisms.
• Add coverage for creating local backups with the same label in db1 and db2, then retrieving both snapshots separately. A second useful case is eviction/removal of an old local backup in one database while another database has the same label.

No additional logs are needed to justify the bug from code inspection. A focused reproduction or regression test would still be useful to lock down the intended SQL/RPC behavior before merging the fix.