- Block cluster restore if existing databases found and cleanup not enabled
- User must press 'c' to enable 'Clean All First' before proceeding
- Prevents accidental data conflicts during disaster recovery
- Bug #24: Missing safety gate for cluster restore
CRITICAL FIXES:
- Encryption detection false positive (IsBackupEncrypted returned true for ALL files)
- 12 cmd.Wait() deadlocks fixed with channel-based context handling
- TUI timeout bugs: 60s->10min for safety checks, 15s->60s for DB listing
- diagnose.go timeouts: 60s->5min for tar/pg_restore operations
- Panic recovery added to parallel backup/restore goroutines
- Variable shadowing fix in restore/engine.go
These bugs caused pg_dump backups to fail through TUI for months.
This is a critical bugfix release addressing multiple hardcoded temporary directory paths
that prevented proper use of the WorkDir configuration option.
PROBLEM:
Users configuring WorkDir (e.g., /u01/dba/tmp) for systems with small root filesystems
still experienced failures because critical operations hardcoded /tmp instead of respecting
the configured WorkDir. This made the WorkDir option essentially non-functional.
FIXED LOCATIONS:
1. internal/restore/engine.go:632 - CRITICAL: Used BackupDir instead of WorkDir for extraction
2. cmd/restore.go:354,834 - CLI restore/diagnose commands ignored WorkDir
3. cmd/migrate.go:208,347 - Migration commands hardcoded /tmp
4. internal/migrate/engine.go:120 - Migration engine ignored WorkDir
5. internal/config/config.go:224 - SwapFilePath hardcoded /tmp
6. internal/config/config.go:519 - Backup directory fallback hardcoded /tmp
7. internal/tui/restore_exec.go:161 - Debug logs hardcoded /tmp
8. internal/tui/settings.go:805 - Directory browser default hardcoded /tmp
9. internal/tui/restore_preview.go:474 - Display message hardcoded /tmp
NEW FEATURES:
- Added Config.GetEffectiveWorkDir() helper method
- WorkDir now respects WORK_DIR environment variable
- All temp operations now consistently use configured WorkDir with /tmp fallback
IMPACT:
- Restores on systems with small root disks now work properly with WorkDir configured
- Admins can control disk space usage for all temporary operations
- Debug logs, extraction dirs, swap files all respect WorkDir setting
Version: 3.42.1 (Critical Fix Release)
PROBLEM: Users could not interrupt backup or restore operations through
the TUI interface. Pressing Ctrl+C or ESC did nothing during execution.
ROOT CAUSE:
- BackupExecutionModel ignored ALL key presses while running (only handled when done)
- RestoreExecutionModel returned tea.Quit but didn't cancel the context
- The operation goroutine kept running in the background with its own context
FIX:
- Added cancel context.CancelFunc to both execution models
- Create child context with WithCancel in New*Execution constructors
- Handle ctrl+c and esc during execution to call cancel()
- Show 'Cancelling...' status while waiting for graceful shutdown
- Show cancel hint in View: 'Press Ctrl+C or ESC to cancel'
The fix works because:
- exec.CommandContext(ctx) will SIGKILL the subprocess when ctx is cancelled
- pg_dump, pg_restore, psql, mysql all get terminated properly
- User sees immediate feedback that cancellation is in progress
- Added WorkDir to Config for custom temp directory
- TUI Settings: new 'Work Directory' option to set alternative temp location
- Restore Preview: press 'w' to toggle work directory (uses backup dir as default)
- Diagnose View: now uses configured WorkDir for cluster extraction
- Config persistence: WorkDir saved to .dbbackup.conf
This fixes diagnosis/restore failures when /tmp is too small for large archives.
Use cases: servers with limited /tmp, 70GB+ archives needing 280GB+ extraction space.
- Added 'Diagnose Backup File' as menu option in TUI
- Archive browser now supports 'diagnose' mode
- Allows users to run deep diagnosis on backups before restore
- Helps identify truncation/corruption issues in large backups
Features:
- restore diagnose command for backup file analysis
- Deep COPY block verification for truncated dump detection
- PGDMP signature and gzip integrity validation
- Detailed error reports with --save-debug-log flag
- Ring buffer stderr capture (prevents OOM on 2M+ errors)
- Error classification with actionable recommendations
TUI Enhancements:
- Automatic dump validity safety check before restore
- Press 'd' in archive browser to diagnose backups
- Press 'd' in restore preview for debug log toggle
- Debug logs saved to /tmp on failure when enabled
Documentation:
- Updated README with diagnose command and examples
- Updated CHANGELOG with full feature list
- Updated restore preview screenshots
- Fix format detection to read database_type from .meta.json metadata file
- Add ensureMySQLDatabaseExists() for MySQL/MariaDB database creation
- Route database creation to correct implementation based on db type
- Add TUI auto-forward in auto-confirm mode (no input required for debugging)
- All TUI components now exit automatically when --auto-confirm is set
- Fix status view to skip loading in auto-confirm mode
- Add WithField and WithFields methods to NullLogger to implement Logger interface
- Change MenuModel to use pointer receivers to avoid copying sync.Once
- Add .golangci.yml with minimal linters (govet, ineffassign)
- Run gofmt -s and goimports on all files to fix formatting
- Disable fieldalignment and copylocks checks in govet
Added cloud storage configuration to TUI settings interface:
- Cloud Storage Enabled toggle
- Cloud Provider selector (S3, MinIO, B2, Azure, GCS)
- Bucket/Container name configuration
- Region configuration
- Access/Secret key management with masking
- Auto-upload toggle
Users can now configure cloud backends directly from the
interactive menu instead of only via command-line flags.
Cloud auto-upload works when CloudEnabled + CloudAutoUpload
are enabled - backups automatically upload after creation.
- Implement context cleanup with sync.Once and io.Closer interface
- Add regex-based error classification for robust error handling
- Create ProcessManager with thread-safe process tracking
- Add disk space caching with 30s TTL for performance
- Implement metrics collection with structured logging
- Add config persistence (.dbbackup.conf) for directory-local settings
- Auto-save/auto-load configuration with --no-config and --no-save-config flags
- Successfully tested with 42GB d7030 database (35K large objects, 36min backup)
- All cross-platform builds working (9/10 platforms)
- Created internal/cleanup package for orphaned process management
- KillOrphanedProcesses(): Finds and kills pg_dump, pg_restore, gzip, pigz
- killProcessGroup(): Kills entire process groups (handles pipelines)
- Pass parent context through all TUI operations (backup/restore inherit cancellation)
- Menu cancel now kills all child processes before exit
- Fixed context chain: menu.ctx → backup/restore operations
- No more zombie processes when user quits TUI mid-operation
Context chain:
- signal.NotifyContext in main.go → menu.ctx
- menu.ctx → backup_exec.ctx, restore_exec.ctx
- Child contexts inherit cancellation via context.WithTimeout(parentCtx)
- All exec.CommandContext use proper parent context
Prevents: Orphaned pg_dump/pg_restore eating CPU/disk after TUI quit
- Removed workloadOption struct and workload-related fields from MenuModel
- Removed workload initialization and cursor tracking
- Removed keyboard handlers (Shift+←/→, 'w') for workload switching
- Removed workload selector display from main menu view
- Removed applyWorkloadSelection() function
- CPU workload type now only configurable via Configuration Settings
- Cleaner main menu focused on actions rather than configuration
Added interactive workload type selector similar to database type selector:
- Three workload options: Balanced | CPU-Intensive | I/O-Intensive
- Switch with Shift+←/→ arrows or 'w' key
- Automatically adjusts Jobs and DumpJobs based on selection:
* CPU-Intensive: More parallelism (2x physical cores)
* I/O-Intensive: Less parallelism (0.5x physical cores)
* Balanced: Standard parallelism (1x physical cores)
UI shows current selection with description:
- Balanced (General purpose)
- CPU-Intensive (More parallelism)
- I/O-Intensive (Less parallelism)
Real-time feedback shows adjusted Jobs/DumpJobs values.
Complements existing --cpu-workload CLI flag with interactive UX.
High Priority Fixes:
- Use configurable ClusterTimeoutMinutes for restore (was hardcoded 2 hours)
- Add comment explaining goroutine cleanup in stderr reader (cmd.Run waits)
- Add defer cancel() in cluster backup loop to prevent context leak on panic
Medium Priority Fixes:
- Standardize tick rate to 100ms for both backup and restore (consistent UX)
- Add spinnerFrame field to BackupExecutionModel for incremental updates
- Define package-level spinnerFrames constant to avoid repeated allocation
Low Priority Fixes:
- Add 30-second timeout per database in cluster cleanup loop
- Prevents indefinite hangs when dropping many databases
Optimizations:
- Pre-allocate 512 bytes in View() string builders (reduces allocations)
- Use incremental spinner frame calculation (more efficient than time-based)
- Share spinner frames array across all TUI operations
All changes are backward compatible and maintain existing behavior.
- Created stripFileExtensions() helper that loops until all extensions removed
- Applied to both --target flag values and extracted archive names
- Handles cases like .sql.gz.sql.gz by repeatedly stripping until clean
- Updated both cmd/restore.go and internal/tui/archive_browser.go
- Ensures database names never contain .sql, .dump, .tar.gz etc extensions
Issue: Interactive backup (single, sample, cluster) showed 'Status: Initializing...'
throughout the entire backup process, identical to the restore issue that was just fixed.
Root cause:
- Status was set once in NewBackupExecution()
- Never updated during the backup process
- Only changed to success/failure at completion
- No visual feedback about backup progress
Solution: Time-based status progression (matching restore pattern)
Added logic in Update() tick handler to change status based on elapsed time:
- 0-2 sec: 'Initializing backup...'
- 2-5 sec: Connection phase:
- Cluster: 'Connecting to database cluster...'
- Single/Sample: 'Connecting to database [name]...'
- 5-10 sec: Early backup phase:
- Cluster: 'Backing up global objects (roles, tablespaces)...'
- Sample: 'Analyzing tables for sampling (ratio: N)...'
- Single: 'Dumping database [name]...'
- 10+ sec: Main backup phase:
- Cluster: 'Backing up cluster databases...'
- Sample: 'Creating sample backup of [name]...'
- Single: 'Backing up database [name]...'
Benefits:
- Consistent UX with restore operations
- Different status messages for single/sample/cluster backups
- Shows what stage of backup is running
- Spinner + changing status = clear progress indication
- Better user experience during long cluster backups
Status checked across all TUI operations:
✅ RestoreExecutionModel - Fixed (previous commit)
✅ BackupExecutionModel - Fixed (this commit)
✅ StatusViewModel - Already has proper loading state
✅ OperationsViewModel - Simple view, no long operations
Issue: Interactive cluster restore showed 'Status: Initializing...' throughout
the entire restore process, making it appear stuck even though restore was working.
Root cause:
- Status and phase were set once in NewRestoreExecution()
- Never updated during the restore process
- Only changed to 'Completed' or 'Failed' at the end
- No visual feedback about what stage of restore was running
Solution: Time-based status progression
Added logic in Update() tick handler to change status based on elapsed time:
- 0-2 sec: 'Initializing restore...' / Phase: Starting
- 2-5 sec: Context-aware status:
- If cleanup: 'Cleaning N existing database(s)...' / Phase: Cleanup
- If cluster: 'Extracting cluster archive...' / Phase: Extraction
- If single: 'Preparing restore...' / Phase: Preparation
- 5-10 sec:
- If cluster: 'Restoring global objects...' / Phase: Globals
- If single: 'Restoring database...' / Phase: Restore
- 10+ sec: 'Restoring [cluster] databases...' / Phase: Restore
Benefits:
- User sees the restore is progressing through stages
- Different status messages for cluster vs single database restore
- Shows cleanup phase when enabled
- Spinner + changing status = clear visual feedback
- Better user experience during long-running restores
Note: These are estimated phases since the restore engine runs in silent mode
(no stdout interference with TUI). Actual operation may be faster or slower
than time estimates, but provides much better UX than static 'Initializing'.
Issue: When enabling cluster cleanup (Option C) in interactive restore mode,
the tool tried to connect to the database to drop existing databases. This
was confusing because:
- Cluster restore itself doesn't use database connections
- It uses CLI tools (psql, pg_restore) directly
- Connection errors were misleading to users
Solution: Changed cleanup to use psql command directly (dropDatabaseCLI)
- Matches how cluster restore works (CLI tools, not connections)
- No confusing connection errors
- Cleaner, more consistent behavior
- Uses postgres maintenance DB for DROP DATABASE commands
Files changed:
- internal/tui/restore_exec.go: Added dropDatabaseCLI() helper function
- Removed dbClient.Connect() requirement for cleanup
- Cleanup now works exactly like cluster restore operations
- Auto-detects existing user databases before cluster restore
- Shows count and list (first 5) in preview screen
- Toggle option 'c' to enable cluster cleanup
- Drops all user databases before restore when enabled
- Works for PostgreSQL, MySQL, MariaDB
- Safety warning with database count
- Implements practical disaster recovery workflow
- Created internal/progress/estimator.go with ETAEstimator component
- Tracks elapsed time and estimates remaining time based on progress
- Enhanced Spinner and LineByLine indicators to display ETA info
- Integrated into BackupCluster and RestoreCluster functions
- Display format: 'Operation | X/Y (Z%) | Elapsed: Xm | ETA: ~Ym remaining'
- Preserves spinner animation while showing progress/time estimates
- Quick Win approach: no historical data storage, just current operation tracking
PROBLEM:
- History displayed ALL entries at once
- With many backups, first entries scroll off screen
- Cursor navigation worked but selection was invisible
- User had to "blindly" navigate 5+ entries to see anything
SOLUTION:
- Added viewport with max 15 visible items at once
- Viewport auto-scrolls to follow cursor position
- Scroll indicators show when there are more entries:
* "▲ More entries above..."
* "▼ X more entries below..."
- Cursor always visible within viewport
RESULT:
- ✅ Always see current selection
- ✅ Works with any number of history entries
- ✅ Clear visual feedback with scroll indicators
- ✅ Smooth navigation experience
FIXED:
- Removed unused cursor variable that was always a space
- Arrow up/down now visibly highlights selected item
- Added position counter (Viewing X/Y)
- Changed selection indicator from ">" to "→"
- Explicit cursor initialization to 0
RESULT:
- ↑/↓ keys now work and show visual feedback
- Current selection clearly visible with highlight
- Position indicator shows which item is selected
- Cluster restores restore multiple databases, not a single target
- Database existence check was failing with exit status 2
- Now shows "Will restore all databases from cluster backup" instead
- Removes confusing warning for cluster restore operations
- Some terminals send ctrl+h instead of backspace
- Added ctrl+h handling in settings.go and input.go
- Ensures backspace works in all terminal emulators
