Ability to delete backups/snapshots

Hi,

Thank you for submitting a feedback :)

We will be review it and update accordingly.

Thanks,

Ofir, JetApps Team

And there's no "re-index destination" so even if you remove it manually, it'll be there. This is basic.

Hi,

Re-index can be executed by running the CLI command

/usr/bin/jetcli backup -vfR reindex

P.S - It's not recommended to make manual changes on the backup destination.

Regards,

Ofir,

JetAppsTeam

REALLY!? This BASIC Feature isn't implemented yet?? I searched for it in WHM, not there. I permanently struggle with space problems. This is definitely what JetBackup can't handle properly. It just refuses to backup instead of deleting old backups. I deactivated snapshots, but it does them anyway. That's really a no go!

Currently we are forced to use the terminal to delete backups or organize them. Then enter a special re-index command... :-/

Please fix this.

Best, Michael

Hi Guys,

First off we'd like to thank everyone for continuing to provide feedback regarding this feature and while we do understand the need for this feature, we would like to take this opportunity to provide you with insight into some of the considerations we have that are keeping us from pursuing this feature.

To clarify, one of our core goals is to provide reliable backups and part of that goal is to ensure that backups generated in JetBackup are as resilient as possible to misconfiguration or unintentional deletion. With this in mind, we design our backup cleanup process to strictly follow the backup job configuration and err towards keeping backups instead of deleting them when there are changes to the configuration.

And just to add, we actually had this briefly implemented on an EDGE version of JetBackup 4 but received negative feedback from clients, with their main concern being that this introduces a possible single point of failure. In case an unauthorized actor gets access to the server/JB admin UI at the root/admin level, they can essentially delete all existing backups and compromise the server leaving admins unable to roll back. This extends to accidental deletion by the admin themselves, creating an irrecoverable situation if the backups were deleted.

We hope that everyone finds the following information insightful and we look forward to continuing to receive feedback from the community!

Best Regards,

JetApps Team

This is not a very strong reason to not implement this. While I can see the sense behind it there is a flaw in the logic. Some destinations are linked using private and public keys such as rsync.net or ssh or whatever uses them. Therefore it only takes a command that can be executed from the cli to remove all backups anyway if the hacker gets access at the root level. So by not providing a way to delete old backups, the flaw exists anyway from the cli.

If you are not going to provide this feature through the admin, then at least update your knowledge base with a supported method of deleting them directly on the destination. At present the way to do this by deleting the .snap folders and reindexing but this is not a process that Jetbackups supports even though it works. So give us a supported method please and we won't need this feature.

5 years waiting for this?

Difficult to believe it's so hard to do, or not considered important enough.

The reason why it's so important is as follows:

The current recommended way of deleting backups is to reduce the retention value. When the backup processing next runs, it auto-removes the backups that are now outside the retention value.

BUT there's a fatal flaw! If the backup server is full (>95% utilised), then the backup processing can't execute, and the auto-removal of backup files can't happen.

So just at the moment you really need to remove backups by the recommended method - you can't!

You're then forced to use the non-recommended CLI method.

Not good.

Also related: we need a way to be able to delete old/abandoned files from the backup server itself.

I'm thinking that a good way/place to do this would be using Jetbackup Management Console:

https://www.jetbackup.com/jetbackup-management-console/

Example: it's just come to my attention that some of our backup servers were still storing backup files from servers that we had decommissioned some time ago.

So clearly we forgot to manually remove these backup files when we decommissioned the servers. Our bad!

But if the Jetbackup MC included the ability to display the backups files sitting on the server (i.e. which source server they belong to), with the option to delete... that would be great.

Agreed this is a must, and hopefully it wont get lost under the "Jetbackup 4" Topic.

This should be a basic feature in every backup tool.

Five years later this option is still not available in the graphical user interface. :-(

Hello Everyone,

At JetBackup, ensuring the safety and integrity of your backups is a top priority. To avoid any accidental/unintended deletions, we currently do not have plans to add a "Delete Snapshot" feature within the JetBackup GUI. This is a security measure to ensure that all snapshot deletions are intentional and controlled.

We have explored ways to potentially implement this feature, such as adding a 2FA for extra security. However, introducing this functionality could open vulnerabilities, potentially allowing bad actors to lock you out of your backups, posing a risk to the very data we aim to protect.

For users who need to delete snapshots, this functionality will continue to be available through our API, ensuring deliberate and secure management of your backups.

Best Regards,

The JetApps Team

@JetApps Requests Admin

Thank you for your continued efforts in improving JetBackup and for providing insights into your considerations regarding the feature request for deleting backups and snapshots manually from the GUI. We understand the importance you place on ensuring backup integrity and preventing accidental or malicious deletions.

However, as paying customers, it’s crucial to remind ourselves that a productive and profitable relationship between software providers and their clients thrives when there’s active listening and responsiveness to customer feedback. We are your partners in this journey, and our needs help shape the evolution of your product. When we, as users, encounter challenges—such as the inability to delete specific backups that may, for example, be unnecessarily consuming expensive third-party storage, or a backup we don't actually need—it becomes a significant pain point that affects the way we use and recommend your product.

There's always a reason to say, "we cannot," but focusing on what can be done is what drives innovation and business growth. Instead of concentrating on the potential risks of implementing a feature, why not explore secure, creative solutions that can meet the needs of your users while maintaining the integrity of the platform?

For example, many platforms handle sensitive requests in ways that balance security and usability. WHMCS, for instance, requires an administrator password to confirm sensitive actions. cPanel, another industry leader (which enables 2FA login already), asks administrators to type the word “DELETE” to confirm critical deletions. These are straightforward yet effective methods to ensure deliberate and intentional actions are taken, without exposing users to unnecessary risk. Implementing a similar confirmation process in JetBackup—such as requiring an administrator password or a typed confirmation—could mitigate the risk of accidental deletions while offering the flexibility users need to manage their storage efficiently. If we accidentally delete a backup, that's our own fault, and at our peril. Even Backblaze B2 has the ability to manually delete files built into their client UI.

By fostering a culture of “what we can do,” you not only demonstrate responsiveness but also show that JetApps is dedicated to remaining competitive and evolving alongside the needs of your users. Businesses grow when they listen to their customers, and this feedback loop can be a powerful tool for JetApps to improve, innovate, and continue to lead in the backup solutions space.

As a customer, I have personally run into this issue of being unable to delete specific backups manually. Given that many of us also pay for storage at third-party sites, having the flexibility to manually remove unnecessary or outdated backups would allow us to manage our storage costs more effectively, which is a crucial factor in our operations.

We appreciate the strides JetApps has made thus far, but in the interest of mutual success, we encourage you to reconsider implementing this feature, whether through the GUI or another secure and user-friendly method (the API is somewhat confusing). We believe that listening to and addressing the needs of your customers will ensure long-term success for both JetApps and the businesses that depend on it.

Thank you for your time and for considering this feedback.

What he said ^^^

Hi Everyone,

Jumping into the conversation to suggest an idea...

While we aim to allow this feature directly from the GUI, there are still concerns around security and preventing human errors.

What if we introduced a 'control file'? For example, if the root user creates a file (e.g., touch /usr/local/jetapps/allow_snapshots_removal) with the correct permissions, the GUI could then enable snapshot deletion.

This approach ensures the feature isn’t enabled by default. For scheduled or periodic deletion, the root user could create the control file, select the snapshots for deletion, and then remove the file afterward.

Thoughts?

Hi Everyone,

I’ve created an internal GIT issue, BASE-2072, to document the findings from this feature request. Once it’s assigned a milestone, I’ll be able to provide an estimated ETA. This should be a straightforward implementation, so I don’t anticipate any issues.

Hi Everyone,

Following up on this to update that whis has been implemented in the latest dev build v5.3.15.10
Added some screenshots of how it looks when enabled, also an error message if you try to delete and the option is disabled

This is very cool HOWEVER, will there be an accompanying error message warning the admin that the --enable-delete-snapshot is still enabled and it should be disabled if not being used?