Hello @mncdev
Thank you for your suggestions — we have discussed them thoroughly with our development team.
From a design perspective, the main constraint we must consider is how backups are actually used in real-world environments, especially with cloud storage. In most cases, users store backups directly in services like Google Drive, Dropbox, or S3, where it is not possible to inspect the contents of a .zip file without downloading it first. This is a fundamental limitation that we cannot bypass.
Because of this, any approach that relies on reading files inside the archive (such as Method 1, or the .wpv marker approach in Method 2) would significantly hinder the initial discovery and scanning stage. Requiring users to download large archives just to identify if they are valid backups would be extremely inefficient and resource-heavy, especially for those with many backups in the cloud.
Our current design is built around this constraint. Instead of relying on file contents, we use a two-layer validation mechanism:
- Strict Filename Patterns: For fast, approximate identification and indexing in cloud storage without needing to download data.
- JSON-based validation inside the archive: For 100% accurate verification of a specific backup, serving a similar purpose to your proposed
.wpv marker approach.
This mechanism is the result of long-term trade-offs between efficiency, accuracy, and compatibility, including support for legacy backups.
Additionally, relying on user-defined or flexible naming is not reliable in practice (e.g. inconsistent naming, forgotten conventions, team environments). A standardized naming scheme, while slightly less flexible, significantly improves stability and maintainability.
For these reasons, we have decided to maintain our current naming design to ensure the highest level of stability. That said, we truly appreciate the time you took to share these ideas with us.
All the best,
