Ability to delete backups/snapshots
Under Consideration
Currently it's not possible to delete a backup or snapshot, you have to wait until it expires and is deleted by the cron.
I'd like to be able to delete a backup or snapshot on demand without having to go to the destination server, manually delete the files, and then re-index the destination.
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
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
Hi,
Thank you for submitting a feedback :)
We will be review it and update accordingly.
Thanks,
Ofir, JetApps Team
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.
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
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
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
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.
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.
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.
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.
Agreed this is a must, and hopefully it wont get lost under the "Jetbackup 4" Topic.
Replies have been locked on this page!