Snapshooter

Notifications work correctly for Droplet backups and for database backups, however they dont exist for Volume backups. This seems to be a huge oversight as you dont know if scheduled volume backups work or not.

Current State: Supports: PostgreSQL, MongoDB, MySQL databases Missing: Generic file volume snapshots Problem: Can't snapshot volumes containing arbitrary files, even if those files are database data directories managed outside Snapshooter's database-specific handlers.

A Slack notification of failed backup job has a a green badge (the line on the left side of the notification) For a failed job this is very misleading! The badge should either be absent or red for failed jobs.

It would be very helpful to have the current Snapshooter IP addresses listed during the setup of a Serverless db backup job or during the server setup for a new Server. That way we don't have to go hunting through the docs to try and find the relevant information (which took me way longer than it should have). Just tried searching the docs for "ip address" and nothing comes up, though I know the info is there somewhere.

In snapshooter there are no user permissions at all - every team member is either owner or member with full read/write access to everything. Right now any member of the team can delete any and all backups! All it takes is one team member to get compromised or be malicious and all your backups can be deleted for all your projects! Need at least basic "view only" role which cannot delete any resources and better to have granular view/write access to individual backup jobs. This is really critical for us to use snapshooter long term

I'm recently using snapshooter for creating backups for multiple resources that my company have in Digital Ocean, we just aquired the Business plan. My particular requirements is regarding Digital Ocean Space Objects Storages, because I found that the S3 Sync makes a great job copying my space in another one, but I'm particularly looking for a way to create a different backup each time the backup job runs, instead of synchronize the existent. I'm wondering if maybe the destination folder can be dynamic path with the date as variable. That could be a good solution for my requirement.

Add GCP Cloud Storage as storage provider, so we don't have to add it as custom S3 compatible resource. GCP should look the same as AWS

"I would like to suggest incorporating a database selection step when adding a MongoDB backup job. The current process for adding a database can be confusing as it might lead one to mistakenly assume that all databases on the selected server will be backed up"