feat: Add logging for backup and restore operations with timestamps

[caffeinated92]

This pull request improves logging for backup and restore operations in the cluster/srv_job.go file by adding detailed start and completion timestamps, as well as elapsed time for each operation. These changes enhance traceability and make it easier to monitor the duration and status of logical and physical backup/restore jobs.

Enhanced logging of backup and restore operations:

• Added log statements to record the start time for physical backup, logical backup, and all logical restore operations (myloader, mysqldump, and script-based restores), including the server URL and backup type. [1] [2] [3] [4] [5]
• Updated log statements to include elapsed time and start time when logical restore operations complete, improving visibility into operation duration. [1] [2] [3]
• Enhanced completion logging for logical backup jobs to include elapsed time, start time, and log level adjustment based on error status.
• Improved SST (State Snapshot Transfer) send operation logging to include start time, elapsed time, and error handling details.

Physical backup completion logging:

• Added a log entry for physical backup completion, showing elapsed time and start time, using metadata from the backup process.

[claude]

Code Review for PR #1337: Add logging for backup and restore operations

Summary

This PR enhances observability by adding comprehensive start/completion timestamps and elapsed time logging across backup and restore operations. The changes are well-intentioned and follow the existing logging patterns in the codebase.

✅ Strengths

1. Consistent logging patterns using existing LogModulePrintf with appropriate log levels and modules
2. Good time formatting with time.RFC3339 for start times and Round(time.Second) for elapsed times
3. Appropriate log levels with conditional selection for backup completion (WARN on error, INFO on success)
4. Comprehensive coverage across physical backup, logical backup, and all three restore types plus SST operations

🔍 Issues Found

1. Typo fixes in log messages

The PR corrects 'restaure' to 'restore' in completion messages. Verify this typo doesn't appear elsewhere in the codebase.

2. SST send error handling improvement (Line ~3335)

Good fix: The added return statement prevents fallthrough to the success log after an error. This is important for correctness.

3. Physical Backup StartTime assumption

The code at lines 3766-3773 relies on Physical.StartTime being set before JobFinishReceiveFile is called. The zero check mitigates this, but verify this invariant holds in all code paths.

📊 Testing Recommendations

Consider adding basic tests for:

• Elapsed time calculations accuracy
• Log message format validation
• StartTime population for all backup types

🔐 Security and Performance

Security: No concerns identified. Timestamps use RFC3339 and no sensitive data is exposed.
Performance: time.Now() calls are minimal and time.Since() operations have negligible overhead.

💡 Minor Suggestion

Consider creating a helper function to reduce duplication across backup completion logs. This would improve maintainability.

Final Assessment

Status: ✅ APPROVE

The PR meaningfully improves observability with solid implementation. The added return statement in SST error handling is a bug fix. The code follows existing patterns well, and logging-only changes pose minimal risk.