With version 9, we have the ability to specify an s3 bucket to as a destination to save backup files. It would be cool if we could also specify a s3 bucket instead of a network share when configuring log shipping.

For now I think I can implement this myself with AWS CLI. But it would be super-deece if this was baked into the SQL Backup Pro product.

I'm a new customer and just started using SQL Backup. When I first start SQL Backup 9, there are some large buttons to import servers, Add a Server, Watch a Demo Video, and Browse the Splashscreen tips. Neither the Demo Video button nor the Splashscreens buttons seem to do anything beyond closing the popup window.

Redgate does not offer any content management for items in the bucket, deferring to AWS's life-cycle management.

The issue then becomes AWS's life-cycle's management only filters on either prefix (a directory name) or tag values. Neither of which you can set or modify with the backup software job level.

A good example: You need multi site coverage for your diffs. So they go to AWS along side all the full backups of the same db. Clearly you'd want to expire the old outdated diffs once worthless, but the fulls you may need to keep the last 3 month's worth.

AWS's life-cycle management, would either look to a file prefix (directory) or a tag/value pair and handle each rule independently. But directory and tagging support does not exist in the software.

AWS backup data gets placed into the root of the bucket.

Redgate does not offer any content management for items in the bucket, deferring to AWS's life-cycle management.

The issue then becomes AWS's life-cycle's management only filters on either prefix (a directory name) or tag values. Neither of which you can set or modify with the backup software job level.

A good example: You need multi site coverage for your diffs. So they go to AWS along side all the full backups of the same db. Clearly you'd want to expire the old outdated diffs once worthless, but the fulls…

Would like to see one single repository similar to SQL Server Management Studio's Central Management Server. Each client should have the same view of SQL Instances and when you had an instance it should be the same for all the DBAs looking at the client. Real pain to have to add all the SQL instances locally and log in to another machine and have to configure it again. Would also have a central location to keep job history repository and possibly run all the jobs from the repository machine rather than creating SQL Agent jobs on each individual machine.

As part of database backup "testing" I randomly select a few backups and restore them on another server. Not difficult to do but time consuming and repetitive, especially for a multi-server farm. Would like a utility to automate this process.

When making changes to servers in the backup interface, I often loose my work due to an unexpected crash or a process that is hung up. Please add an option to save changes to the servers.dat file without closing the interface.

Need the ability to do backups based by certificate, not just by a pre-shared key. It'll be more secure if a private key needs to be in a keystore, rather than just a shared secret anyone could brute force.

Whether the keystore/certs are stored in MSSQL's built in certificate support, or through the compact database, or through the certificates snap-in (perhaps on the service account), or through some other means; could be up for discussion. Selection of certificate by fingerprint or serial number via the Backup/restore commands... Additional ability to use a pre-shared key to lock or unlock the certificate.

The ability to multi-select restore items on the Restore (Step 1 of 4), there could be several hundred log backups throughout the day and although you can add/remove ALL, you can only select/remove one at a time (tried shift and/or ctrl) if the chain is broken or needs adjusting

The product pages on the website should list the latest version available.

Just makes it nice and easy to see what the latest version available is, I rarely look at the redgate site (no need to, redgate backup just works, been using it for 3 years and only recall two failures that needed investigation and none that required redgate support help).

If anything on the Windows side of the house prevents deletion of SQL Backup's own .log files, the Backup Service wastes time hunting repeatedly for said file(s) to delete, which can considerably (in my case from 2 seconds to 45 minutes per database) lengthen the execution duration, meaning that the potential data-loss window grows to the length of each run, which is unacceptable behavior.

Though rare, changing a service account can precipitate this run extension. Though rare, SQL Backup's response is to only warn of a deletion failure, and try again next time.

SEPARATION OF CONCERNS is a well-establish programming paradigm. Why doesn't SQL Backup adhere to it? What, in reality, does a housekeeping task that cleans up old .log files, have to do with the mission-critical job of taking data and transaction log backups?

May I politely request you split the functionality so nobody in future is subjected to delayed backups and the risks associated with backups not being taken at the appropriate interval.

If anything on the Windows side of the house prevents deletion of SQL Backup's own .log files, the Backup Service wastes time hunting repeatedly for said file(s) to delete, which can considerably (in my case from 2 seconds to 45 minutes per database) lengthen the execution duration, meaning that the potential data-loss window grows to the length of each run, which is unacceptable behavior.

Though rare, changing a service account can precipitate this run extension. Though rare, SQL Backup's response is to only warn of a deletion failure, and try again next time.

The ability to automatically copy backups to Amazon cloud drive, Microsoft one drive, Google drive, Dropbox, iCloud drive, etc. would be a great feature. Allow the customer to choose which cloud services they want to use.

We are looking forward for some more reporting in SQL Backup. Actually it would be nice to have a report with the backup scheduling of a selected server and databases. This way we get an better overview of a our backup strategy at all. It would be nice to now which database it's backuped at which time, something like that.

Starting with SQL Server 2012 SP1 CU2 users have had the ability to backup databases to a URL. This functionality is backwards compatible (through the GUI, but not T-SQL) to 2008. However, prior to SQL 2014, there was no way to encrypt backups without using transparent data encryption. What would be a really nice to have is the ability to backup a database to Azure blob storage. This would likely need to be a local backup that was moved to Azure, but it could use the native encryption in SQL Backup.