IDERA strives to ensure our products provide quality solutions for your SQL Server needs. The following known issues are described in this section. If you need further assistance with any issue, please contact Support (www.IDERA.com/support).
Known Issues for 8.4.2
Installation
- The SQL Safe Filter Service and SQL Safe OLR Service can be installed on Windows version 10 and later once you disabled the Secure boot (in the VM properties for a VM or the BIOS settings for a physical machine).
Object Level Recovery
Policies
- Statuses for deleted databases are not removed from the Last Operation Status section of the Policy Status view. Please contact Support for further assistance.
Known Issues for 8.4.1
Native Backup
- When submitting an ad-hoc native backup operation against SQL Safe Agents prior to 8.4 version, the operation will not perform any work. Native backup operations are only supported for SQL Safe Backup Agents 8.4 version and later.
Known Issues for 8.4
Cloud Support
- When backups fail while using Windows Azure, partial files will remain unless the user deletes them manually.
IDERA Dashboard
Installation
- When installing or upgrading SQL Safe, the installer is not able to parse SQL Server instance names with a space within the entered name. For example, use "SERVER,1433" instead of "SERVER, 1433".
Licensing
- The licenses users add should be valid for the Centralized Licensing model. When Centralized Licensing is enabled, all licensing information is managed using the SQL Safe Management Service and each of the individual SQL Safe Backup Agent licenses are removed.
Object Level Recovery
- The SQL Safe Management Service and SQL Safe Backup Agent must be upgraded to 8.4 version in order to run Object Level Recovery successfully.
- Object Level Recovery operations can fail when the SQLsafe repository database is hosted on a SQL Server 2014 or SQL Server 2016 instance with the following error: "Could not load file or assembly 'Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)". The recommended workaround is to use the InstantRestore or Virtual Database feature to recover the database in an expedited fashion.
Policies
- Users should take into account that time fields for the Policies, Operation History, and Databases tabs in the SQL Safe Web Console are currently expressed in the GMT time zone.
- In the web console Policies tab, options to start jobs and disable policy are not available.
- SQL Server Agent service account authentication for the Network path provided as Primary location in Log Shipping Policy wizard fails with an error even though the Service account has full permissions to the shared path.
TSM
- Low-level file selection is not working properly with TSM backup/restore.
Virtual Database
SQL Virtual Database does not support compressed native backup from SQL Server 2014 and SQL Server 2016 instances. Attempting to mount these kinds of backups results in the following error: "The header for the backup archive cannot be read. The file may not be a valid backup archive".
When using an appended SQL Safe Backup file, mounting a virtual database automatically selects the first backup set within the backup file.
Other Issues
After registration, SQL Safe Web Console will list all available instances in the repository. Users have to use the options to Bulk Edit credentials to change credentials for those instances they are not able to monitor.
The SQL Safe Web Console is not currently sending e-mail notifications for Restore Operations.
"Agent deployment service account" changes made in the desktop console are not replicating in the web console.
Known Issues for 8.3
Cloud Support
- When backups fail while using Windows Azure, partial files will remain unless the user deletes it manually.
IDERA Dashboard
Installation
- When installing or upgrading SQL Safe, the installer is not able to parse SQL Server instance names with a space within the entered name. For example, use "SERVER,1433" instead of "SERVER, 1433".
Licensing
- The licenses users add should be valid for the Centralized Licensing model. When Centralized Licensing is enabled, all licensing information is managed using the SQL Safe Management Service and each of the individual SQL Safe Backup Agent licenses are removed.
Policies
- Users should take into account that time fields for the Policies, Operation History, and Databases tabs in the SQL Safe Web Console are currently expressed in the GMT time zone.
- In the web console Policies tab, options to start jobs and disable policy are not available.
- SQL Server Agent service account authentication for the Network path provided as Primary location in Log Shipping Policy wizard fails with an error even though the Service account has full permissions to the shared path.
TSM
- Low-level file selection is not working properly with TSM backup/restore.
VDB
- Users who plan to install Safe 8.0 on the same system as VDB should obtain the VDB 2.1 buddy drop which addresses compatibility issues between the two products. Please contact IDERA Support for more information.
- After installing SQL Safe, existing virtual databases may not be accessible. IDERA recommends to first upgrade with the VDB 2.1 buddy drop, unmount virtual databases, install SQL Safe, and then recreate the respective VDBs. Contact IDERA Support for more information.
- When uninstalling SQL Safe, users may need to reboot their computers to remove the SQLvdb Filter Service.
Other Issues
After registration, SQL Safe Web Console will list all available instances in your repository. Users have to use the options to Bulk Edit credentials to change credentials for those instances they are not able to monitor.
The SQL Safe Web Console is not currently sending e-mail notifications for Restore Operations.
Agent deployment service account changes made in the desktop console are not replicating in the web console.
Known Issues for 8.2
IDERA Dashboard
- Instances removed from web and desktop console are still displaying under Dashboard Managed Instances.
Policies
- SQL Server Agent service account authentication for the Network path provided as Primary location in Log Shipping Policy wizard fails with an error even though the Service account has full permissions to the shared path.
- Users may find the option for wildcards is not available when defining databases to backup in the respective policy wizard.
- In the web console Policies tab, options to start jobs and disable policy are not available.
TSM
- Low level file selection is not working properly with TSM backup/restore.
VDB
- Users who plan to install Safe 8.0 on the same system as VDB should obtain the VDB 2.1 buddy drop which addresses compatibility issues between the two products. Please contact IDERA Support for more information.
- After installing SQL Safe, existing virtual databases may not be accessible. IDERA recommends to first upgrade with the VDB 2.1 buddy drop, unmount virtual databases, install SQL Safe, and then recreate the respective VDBs. Contact IDERA Support for more information.
Other Issues
- After registration, SQL Safe Web Console will list all available instances in your repository. Users have to use the options to Bulk Edit credentials to change credentials for those instances they are not able to monitor
- Users should take into account that time fields for the Policies, Operation History, and Databases tabs in the SQL Safe Web Console are currently expressed in the GMT time zone.
- When uninstalling SQL Safe, users may need to reboot their computers to remove the SQLvdb Filter Service.
- The SQL Safe Web Console is not currently sending e-mail notifications for Restore Operations
- Agent deployment service account changes made in the desktop console are not replicating in the web console.
Known issues for 8.0
- To upgrade from build 8.0.0.423 to Hotfix build (8.0.0.503) users need to follow these steps:
- Open the installer to prompt the upgrade.
- Type the credentials for the newly created SQLsafe REST service.
- When upgrading the instance of SQL Safe, the installer displays the value to be added to the location property.
- Access the web application. When an "exception" message is displayed, select the option "Redirect me to Dashboard."
- Go to the Administration tab of the IDERA Dashboard, select Manage Products, and edit the respective SQL Safe instance. In the Location field, add the value specified during installation.
- Restart the IDERADashboardCoreService (Automatically the IDERADashboardWebAppService service is restarted.)
- After registration, SQL Safe Web Console will list all available instances in your repository. Users have to use the options to Bulk Edit credentials to change credentials for those instances they are not able to monitor.
- Users should take into account that time fields for the Policies, Operation History, and Databases tabs in the SQL Safe Web Console are currently expressed in the GMT time zone.
- The Progress bar of the Operation History tab in the SQL Safe Web Console does not update its progress during the operation execution.
- When uninstalling SQL Safe, users may need to reboot their computers to remove the SQLvdb Filter Service.
- The SQL Safe Web Console is not currently sending e-mail notifications for Restore Operations.
- When uninstalling SQL Safe, users should manually remove the product from their IDERA Dashboard before rebooting their system.
- Users who plan to install Safe 8.0 on the same system as VDB should obtain the VDB 2.1 buddy drop which addresses compatibility issues between the two products. Please contact
for more information. - After installing SQL Safe, existing virtual databases may not be accessible. IDERA recommends to first upgrade with the VDB 2.1 buddy drop, unmount virtual databases, install SQL Safe, and then recreate the respective VDBs. Contact
for more information.
Known issues for 7.4
- When a backup operation in SQL Safe is performed at the same time as the native SQL Server, the successful backup job on SQL Safe may not always show the correct timestamp in the file name of the repository
- When upgrading from an older version, the user may experience Log Shipping policies with an "out of date" message in the console. Clicking the "out of date" link will fix this issue.
- Instead of being assigned the default location set in Preferences, users may find that location paths of stripped files are the same as that of the mirror paths when changing from single to stripped location type.
- Users may find that pressing the "Enter" key in the Backup, Restore and Log Shipping wizards may lead them to the consecutive pages instead of inserting new lines in fields as it is done in the Backup Policy Wizard.
- When setting up a log shipping wizard with a cluster instance, users may find that secondary database file location does not display the same path as the one configured in the respective wizard but it displays the location from the primary database.
- Users may get a Last operation status of "Backups did not start as scheduled" in policies that are configured to run full and differential backups at specific times and where backups are done with no compression and no encryption.
- When running Instant Restore, users may experience problems if they have the same drive mounted as a drive letter and as a folder and they are using both paths for the Instant Restore procedure: the backup file accessed via the drive letter and the data files accessed via the folder path.
- Users may experience timeouts with the Instant Restore processes over a SQL Server 2012 SP1 with cumulative updates.
Users may find that when the InstantRestore process is running in a clustered SQL Server and a failover occurs during the Hydration process, the Management Console displays the InstantRestore and Hydration processes as halted. The operation will not complete until the cluster is failed back to the original node where the operation was started.
- Users that select the SQL Safe Backup Agent to create policies on servers where the timezone has been changed may need to restart the SQL Safe Backup Agent service to update the timezone and ensure policies run on the correct schedules.
Previous known issues
SQL Safe Repository no longer supports SQL Server 2000
SQL Safe Repository no longer supports SQL Server 2000. Supported versions include:
- SQL Server 2008 R2
- SQL Server 2008 Standard and Enterprise Editions
- SQL Server 2005 Standard and Enterprise Editions SP1 or later
SQL Safe no longer supports Itanium
SQL Safe 7.0 and later does not support the Itanium processor architecture. For more information, see the software requirements.
Pentium II processors are not supported
You should not install SQL Safe on a computer running a Pentium II processor. For more information, see the hardware requirements.
User must select the SQL Server hosting the Repository when using the Maintenance wizard
Users of the SQL Safe Maintenance wizard to modify, repair, or remove this version of SQL Safe must click Browse to select the current SQL Server hosting the Repository in the SQL Safe Repository window of the wizard. The wizard does not let you continue until an entry appears in the SQL Server hosting the Repository field.
Backup file names that use the %timestamp% macro may change when upgrading to SQL Safe 6.5 or later
When some users upgrade to SQL Safe 6.5 or later, the backup file names using the %timestamp% macro may change. This issue affects users who have SQL Safe groom their backup files at backup time, using either the -delete command line option or the Remove files older than option in the Backup Policy wizard. Previous versions expand %timestamp% to the UTC time of the backup.
Beginning with SQL Safe 6.5, %timestamp% expands to the local time of the backup. As a result, SQL Safe may write new backups to files already created by an earlier version of SQL Safe immediately after upgrading. By default, SQL Safe appends to backup files and this issue does not occur as the new backup appends to the existing file. This situation resolves itself after the time difference between UTC and local time passes. For example, this issue is resolved after five hours in the Central Standard Time zone (US).
Note that if you specify to overwrite, SQL Safe overwrites the existing files instead of appending the new information. If you upgrade from a release earlier than SQL Safe 6.4, appends fail and display an error message.
Setup program removes previous version when upgrade fails
If the upgrade fails while you are upgrading from a previous version of SQL Safe, the setup program removes the previous version from the SQL Server computer on which you attempted the upgrade.
XSP installation fails on clustered SQL Server instances
When you use the Agent Only install to manually deploy the SQL Safe Backup Agent to a clustered SQL Server instance, the corresponding SQL Safe XSP installation will fail. After the Backup Agent install completes, you can manually install the SQL Safe XSP.
For more information, see the Using the SQL Safe XSP Technical Solution located in the Documentation folder (by default, C:\Program Files\IDERA\SQL Safe\Documentation).
Remote Backup Agent install fails when SQL Server is not installed
In order to install the SQL Safe Backup Agent remotely, the computer from which you install SQL Safe must have a version of SQL Server already installed. For more information, see the software requirements.
Table Restore wizard is no longer available in SQL Safe version 6.0 or later
To restore objects and data from your backup files, use the new IDERA SQL virtual database tool. For more information, see Recover objects using SQL virtual database.
FIPS-compliant encryption no longer requires additional software when installing SQL Safe version 6.0 or later
In a FIPS-compliant environment, SQL Safe uses only FIPS-compliant algorithms to encrypt your backup files. These encryption methods do not require any additional software. For more information, see Ensure FIPS compliance.
Upgrade any Backup Agents that perform TSM backups
Due to the extensive TSM enhancements included in SQL Safe 6.4 and later, older Backup Agents are not compatible with 6.4. To ensure you can continue backing up your SQL Server data to TSM, upgrade any Backup Agent that is used to perform TSM backups in your environment.
64-bit users need additional steps to install reports
Users with 64-bit installations must follow different steps to install reports. For more information, see IDERA solution 3891, "Where do I find the SQL Safe reports," in the knowledge base on Support (www.IDERA.com/support).
SQL Safe 4.0 users who upgrade to SQL Safe 7.1 or newer cannot use existing backup policies as part of new restore policies
SQL Safe 4.0 users who upgrade to SQL Safe 7.1 or newer receive error messages if they attempt to create and then run a restore policy that includes a backup policy created on the earlier version of SQL Safe.
SQL Safe Management Service logging multiple grooming events per day
Some users may notice the SQL Safe Management Service logging multiple grooming events in the Windows Application log each day. SQL Safe should be logging only one such event per day.
Attempting to restore a database from the list of backups on the SQL Server details page fails
A failure results when you attempt to restore a database file by right-clicking a file backup in the Backup/Restore Operation Status list and select Restore Database. To avoid this issue when restoring a file backup, click Restore > Database Files from the menu and complete the available restore wizard. You can also access the wizard from the Servers tree by right-clicking the appropriate SQL Server instance and selecting Restore Database(s) Files.
InstantRestore performance is affected by whether the SE_MANAGE_VOLUME_NAME privilege is on your SQL Server
Enabling the SE_MANAGE_VOLUME_NAME privilege for your SQL Server account improves general SQL Server file I/O performance as well as SQL Safe InstantRestore. If this privilege is not enabled for the SQL Server Service, InstantRestore performance could be negatively impacted, just as with SQL Server itself. The degree of impact varies depending on environmental conditions. For more information about SQL Server Instant File Initialization, see the Microsoft Knowledge Base article located at Database Instant File Initialization.
InstantRestore appears to stall when restoring databases that contain read-only file groups
SQL Safe 7.0 Beta hydration appears to stall at 99% complete when restoring databases that contain read-only file groups. SQL Server triggers InstantRestore hydration when it performs read/write I/O on the database files. Because SQL Server does not perform read/write I/O on the read-only files, hydration does not begin. Eventually, hydration begins when SQL Server performs read I/O on the files. You can delete the database if you experience this issue.
Adding a new drive requires you to restart the InstantRestore Service
When you add a new drive to a server, you must restart the SQL Safe Filter Service to make sure that the SQL Safe Filter driver is attached to the new drive. When the SQL Safe Filter Service starts, it attaches the SQL Safe Filter driver to all the fixed drives on the server. If you add a new drive after the service starts, the driver is not attached and any files created on this drive during InstantRestore do not function correctly. To avoid this issue, simply restart the SQL Safe Filter Service after adding any new drive.
Not all files are removed when you delete a database restored using InstantRestore
Some files may remain after you attempt to delete a database previously restored using the InstantRestore feature. In most cases, you can manually delete these mdf, ndf, ldf, and vbm files. If the files are locked, restart either the SQL Safe Filter Service or the SQL Server Instance and then delete the files manually.
Offline SQL Safe Web Help may display a blank page
Some users experience a blank page when pressing F1 and using the offline SQL Safe Help. If this issue occurs, access the online version of SQL Safe 7.1 Help at http://www.IDERA.com/help/SQL Safe/7-1/web/default.htm.
SQL Safe Backup Agent may stop unexpectedly
The SQL Safe Backup Agent may stop unexpectedly and SQL Safe displays an error similar to, ".NET Runtime version 2.0…-Fatal Execution Engine Error." Microsoft recommends that users make sure that their environments include the following patches:
Importing backup archive sets may result in an error
SQL Safe may experience an issue when you attempt to import backup archive sets into your Repository.
Logins data archived only on Full backups
SQL Safe archives Logins data only when you perform a Full backup. SQL Safe does not archive this data when you perform a Differential or Log backup. You can restore Logins data only when you use a single backup set. When you specify multiple backup sets such as Full, Differential, and Log, you cannot restore Logins data.
Policy views may be blank after upgrading to version 6.6
The new granular alert notifications available in version 6.6 provide more detailed feedback about policy compliance and status. Because policy jobs created with SQL Safe 6.4 or earlier do not support this feature, the Management Console policy views will not display compliance status related to previous backup or restore operations. Instead, the policy views will track the policy status from the time you upgraded. To see the status of previous backup and restore operations, use the backup/restore operation status pane on the instance and database status views.
No Restore Policy support for backup files stored on TSM Servers
The SQL Safe 6.6 Restore Policy does not support restoring a database from a backup file stored on a TSM Server.
Metadata for SQL virtual database is not generated
SQL Safe is unable to generate SQL virtual database metadata for backups that use the following options:
- SQL Server 2008 databases that use FILESTREAM to manage unstructured data
- Read-write file groups
- File backups
Errors occurring when saving changes may delete policies
If an error occurs while saving changes to an existing policy, the policy may be deleted.
InstantRestore appears to stall when restoring databases that contain read-only file groups
SQL Safe 7.0 Beta hydration appears to stall at 99% complete when restoring databases that contain read-only file groups. SQL Server triggers InstantRestore hydration when it performs read/write I/O on the database files. Because SQL Server does not perform read/write I/O on the read-only files, hydration does not begin. Eventually, hydration begins when SQL Server performs read I/O on the files. You can delete the database if you experience this issue.
Adding a new drive requires you to restart the InstantRestore Service
When you add a new drive to a server, you must restart the SQL Safe Filter Service to make sure that the SQL Safe Filter driver is attached to the new drive. When the SQL Safe Filter Service starts, it attaches the SQL Safe Filter driver to all the fixed drives on the server. If you add a new drive after the service starts, the driver is not attached and any files created on this drive during InstantRestore do not function correctly. To avoid this issue, simply restart the SQL Safe Filter Service after adding any new drive.
Not all files are removed when you delete a database restored using InstantRestore
Some files may remain after you attempt to delete a database previously restored using the InstantRestore feature. In most cases, you can manually delete these mdf, ndf, ldf, and vbm files. If the files are locked, restart either the SQL Safe Filter Service or the SQL Server Instance and then delete the files manually.
InstantRestore Hydration statistics are incorrect if the IR Server restarts during Hydration
During the Hydration phase of the InstantRestore feature, if the IR filter service is restarted, the statistics incorrectly show the hydration process reset to zero. This is not accurate as hydration correctly picks up where it left off in the process.
SQL Safe is a high-performance backup and recovery solution for your SQL Servers. Learn more > > |
