At the moment, we’re holding off on adding any further cloud storage options to SQL Backup Pro. There are various ways in which backup to Azure (or other cloud storage service) can be achieved fairly easily outside of SQL Backup, for eg, both Azure and AWS provide command-line tools that can help here (ref. https://azure.microsoft.com/en-gb/documentation/articles/storage-azure-cli/ , http://docs.aws.amazon.com/cli/latest/reference/s3/sync.html ). Obviously we’ll keep our eyes open to customer feedback in this area.
[I've also cleaned out as much of the spam as I can spot.]
Reporting is a tricky area, since requirements across a large base of customers are very variable – if you’re not careful, you end up building a generic reporting product within your product. So a common reporting strategy taken by products like SQL Backup Pro, is to ship with some pre-canned reports, and then make it possible for people to roll their own ad-hoc queries for needs that fall outside of the pre-canned reports.
This UserVoice suggestion includes some interesting candidate pre-canned reports: thanks for the ideas; and I’d like to share some information on where data is collected and stored by SQL Backup Pro, which should at least makes ad-hoc querying easier to do.
The data is stored in two locations:
- on each server running the SQL Backup Pro engine, in a SQL CE database (one database for each instance). You can find these at:
C:\ProgramData\Red Gate\SQL Backup\Data\[instance_name]\data.sdf
- on the PC where you run the SQL Backup Pro UI, in a SQL Lite database; this is a local cache of the data collected from each server running the SQL Backup engine. You can find this at:
C:\Users\[username]\AppData\Local\Red Gate\SQL Backup\Server Data\1.dat
There are various tools that can be used to query such databases (for eg, Database .NET, http://fishcodelib.com/database.htm)).
Note that some of the data displayed in the UI is queried from elsewhere, or calculated as needed. For eg, a backup job’s schedule isn’t stored here, since that scheduled could be changed directly in SSMS, so we’d get out of sync. You can directly query this from the msdb database (eg, see https://www.mssqltips.com/sqlservertip/2561/querying-sql-server-agent-job-information/).
Please note that these two database schemas are not managed schemas, and whilst it’s unlikely that they’ll change we can’t commit to not making changes that might break any custom integration done against them. Also, sometimes SQL Backup Pro will takes an exclusive lock against the SQL Lite database, so you may want to take a copy before running a query against it.
Hope this is of some help.
SQL HyperBac was designed to be non-invasive, so moving from SQL HyperBac is as simple as uninstalling it. Once this is done, then when your existing backup jobs next run, the HyperBac engine will no longer intercept I/O to/from the disks, and hence will not compress/encrypt files, and you'll end up with native SQL Server backup files.
Here are a few additional considerations:
1) In theory, you might want to change the file extensions in your backup creation jobs (eg, from “.hbc” to “.bak”); however, the file extension is merely a SQL Server convention, so this is not required.
2) If you were planning on moving to SQL Backup Pro, then the situation is exactly the same as for any new user of SQL Backup Pro: you either need to recreate your backup jobs, or it may be possible to convert existing SQL Server Maintenance Plans into SQL Backup Pro jobs (see http://documentation.red-gate.com/display/SBU7/Maintenance+Plan+Conversion+Wizard ).
3) If at some stage in the future, you wished to restore a backup file created using SQL HyperBac, then there's some information on where to get hold of the HyperBac installers, and/or the file conversion utilities, in the SQL HyperBac support forum (direct link to post is https://forums.red-gate.com/viewtopic.php?f=124&t=78230 ).
I've just posted an update to another suggestion ( https://sqlbackup.uservoice.com/forums/91737-sql-backup/suggestions/2676099-prevent-refresh-repositioning-the-activity-histo ), about a patch release of the SQL Backup UI that should address the refresh problem mentioned at the end of this suggestion.
One further caveat: the ERASEFILES and COPYTO options still won't work due to the error that's raised by SQL Server.
Hi Nick, I see that you've provided more information to MaxB; please feel free to extend the description here, if you want to get input from others.
Hi Nick, thanks for the feedback, could you expand a little on what specifically you have in mind? (eg, where in the UI you're suggesting making the changes)
What version of SQL Backup are you using?
From 7.1 (released 21st June this year), we increased the maximum size of the script to 1MB - equivalent to about 100,000 characters in your script.(This is for the XPROC scripts not the command line). Prior to this version, it was 64KB.
Release notes for 7.1 are here: http://www.red-gate.com/supportcenter/Content?p=SQL%20Backup&c=SQL_backup\articles\version_7xx_SQLBackup.htm
I hope this addresses your issue. Let me know if you have any further questions.
Project manager, SQL Backup team