MokoConsulting/MokoJoomBackup
1
0
Fork 0
Code Issues 30 Pull Requests 1 Packages Projects Releases 1 Wiki Activity

Feature: backup integrity verification (SHA-256 checksums) #15

New Issue
Open
opened 2026-06-02 20:29:29 +00:00 by jmiller · 1 comment
jmiller commented 2026-06-02 20:29:29 +00:00
Owner
Copy Link
Copy Source

Store and verify SHA-256 checksums for backup archives.

Description

After creating a backup, compute and store a SHA-256 hash. Provide a "Verify" button in the admin UI that re-computes the hash and compares.

Requirements

  • SHA-256 computed after ZIP creation
  • Hash stored in backup record (new checksum column)
  • "Verify Integrity" button in backup list/detail
  • Verification result shown to admin
  • Hash included in remote upload metadata
Store and verify SHA-256 checksums for backup archives. ## Description After creating a backup, compute and store a SHA-256 hash. Provide a "Verify" button in the admin UI that re-computes the hash and compares. ## Requirements - [ ] SHA-256 computed after ZIP creation - [ ] Hash stored in backup record (new `checksum` column) - [ ] "Verify Integrity" button in backup list/detail - [ ] Verification result shown to admin - [ ] Hash included in remote upload metadata
jmiller added the type: featurepriority: mediumcomponent: enginestatus: ready labels 2026-06-02 20:29:29 +00:00
jmiller commented 2026-06-02 20:29:29 +00:00
Author
Owner
Copy Link
Copy Source

Testing Plan

TC-F2.1: Checksum generation

  1. Run backup
  2. Verify backup record has non-empty checksum field
  3. Manually compute SHA-256 of the archive file
  4. Verify it matches the stored checksum

TC-F2.2: Integrity verification

  1. Click "Verify" on a backup record
  2. Verify success message
  3. Modify the archive file (corrupt it)
  4. Click "Verify" again
  5. Verify failure message with mismatch details

TC-F2.3: Missing file

  1. Delete the archive file from disk
  2. Click "Verify"
  3. Verify appropriate error message
## Testing Plan **TC-F2.1: Checksum generation** 1. Run backup 2. Verify backup record has non-empty checksum field 3. Manually compute SHA-256 of the archive file 4. Verify it matches the stored checksum **TC-F2.2: Integrity verification** 1. Click "Verify" on a backup record 2. Verify success message 3. Modify the archive file (corrupt it) 4. Click "Verify" again 5. Verify failure message with mismatch details **TC-F2.3: Missing file** 1. Delete the archive file from disk 2. Click "Verify" 3. Verify appropriate error message
Sign in to join this conversation.
Labels
Clear labels
component: admin
Admin UI and views
 component: api
REST API
 component: engine
Backup/restore engine
 component: remote
Remote storage (FTP/GDrive)
 component: scheduler
Scheduled tasks
 priority: critical
Must fix before release
 priority: high
Important for release
 priority: low
Nice to have
 priority: medium
Normal priority
 status: blocked
Blocked by dependency
 status: ready
Ready for development
 type: bug
Something is broken
 type: docs
Documentation
 type: feature
New feature or enhancement
 type: testing
Testing and QA
bug
Something is not working
 chore
Maintenance and housekeeping
 documentation
Documentation improvements
 enhancement
Improvement to existing functionality
 feature
New feature or request
 pending: dependency
Blocked by another issue or external dependency
 pending: deployment
Tested and approved, awaiting deployment to production
 pending: design
Needs UI/UX or architecture design before implementation
 pending: documentation
Feature works, needs documentation/wiki update
 pending: feedback
Awaiting feedback or decision from stakeholder
 pending: review
Implementation complete, awaiting code review
 pending: testing
Feature implemented but not yet tested
 priority: critical
Must fix immediately
 priority: high
Should fix soon
 priority: low
Nice to have
 priority: medium
Fix when convenient
 refactor
Code restructuring without behavior change
 roadmap
Planned feature or enhancement tracked on the roadmap
 scope: client
Client-specific work
 scope: dolibarr
Dolibarr modules and customizations
 scope: infrastructure
Server, CI, backups, monitoring
 scope: joomla
Joomla templates and extensions
 scope: waas
MokoWaaS platform
 security
Security vulnerability or hardening
 status: blocked
Waiting on external dependency
 status: duplicate
Duplicate of another issue
 status: in-progress
Being worked on
 status: needs-review
Ready for review
 status: wontfix
Will not be addressed
No labels component: engine priority: medium status: ready type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jmiller (Jonathan Miller)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/MokoJoomBackup#15
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?