[BUG] Potential non-uniqueness of backup_id when multiple backups created simultaneously

[likelios]

Describe the bug

Backup ID is generated using a timestamp with second precision only (format: YYYYMMDDThhmmss, e.g., 20260310T102740). When multiple backup requests are processed concurrently within the same second, they all receive identical backup IDs. This leads to collisions, potential data overwrites, and issues when managing backups (listing, evicting, restoring).

To Reproduce

Steps to reproduce the behavior:

1. Send two simultaneous POST /backup requests to the backup daemon API:

   # Run these two commands at the same time (in two terminals)
   curl -u username:password -XPOST http://localhost:8080/backup &
   curl -u username:password -XPOST http://localhost:8080/backup &

2. Observe the backup IDs returned in the responses.

3. Both responses will contain the same ID (if both requests were processed within the same second):

   Response 1: 20260310T102740
   Response 2: 20260310T102740
   

4. Check the list of backups via GET /listbackups — only one backup appears, or they conflict in the storage.

Expected behavior

Each backup should have a globally unique identifier, even when created in parallel. Examples of possible solutions:

• Add milliseconds: YYYYMMDDThhmmss.SSS
• Add random suffix: YYYYMMDDThhmmss_abc123
• Use UUID alongside timestamp: 20260310T102740_8f3b1c2a
• Ensure sequential processing with uniqueness guarantee

Screenshots

Not applicable, but here's a clear example of the issue:

Request	Time	Generated ID
First	10:27:40.123	20260310T102740
Second	10:27:40.456	20260310T102740 (should be unique)

Environment:

• Application --
• K8S Version: --