Page History
...
- When a backup operation in SQLsafe SQL Safe is performed at the same time as the native SQL Server, the successful backup job on SQLsafe 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 SQLsafe SQL Safe Backup Agent to create policies on servers where the timezone has been changed may need to restart the SQLsafe SQL Safe Backup Agent service to update the timezone and ensure policies run on the correct schedules.
Previous known issues
SQLsafe SQL Safe Repository no longer supports SQL Server 2000
SQLsafe 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
SQLsafe SQL Safe no longer supports Itanium
SQLsafe 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 SQLsafe 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 SQLsafe SQL Safe Maintenance wizard to modify, repair, or remove this version of SQLsafe SQL Safe must click Browse to select the current SQL Server hosting the Repository in the SQLsafe 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 SQLsafe SQL Safe 6.5 or later
When some users upgrade to SQLsafe SQL Safe 6.5 or later, the backup file names using the %timestamp% macro may change. This issue affects users who have SQLsafe 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 SQLsafe SQL Safe 6.5, %timestamp% expands to the local time of the backup. As a result, SQLsafe SQL Safe may write new backups to files already created by an earlier version of SQLsafe SQL Safe immediately after upgrading. By default, SQLsafe 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, SQLsafe SQL Safe overwrites the existing files instead of appending the new information. If you upgrade from a release earlier than SQLsafe SQL Safe 6.4, appends fail and display an error message.
...
If the upgrade fails while you are upgrading from a previous version of SQLsafeSQL Safe, the setup program removes the previous version from the SQL Server computer on which you attempted the upgrade.
...
When you use the Agent Only install to manually deploy the SQLsafe SQL Safe Backup Agent to a clustered SQL Server instance, the corresponding SQLsafe SQL Safe XSP installation will fail. After the Backup Agent install completes, you can manually install the SQLsafe SQL Safe XSP.
For more information, see the Using the SQLsafe SQL Safe XSP Technical Solution located in the Documentation folder (by default, C:\Program Files\Idera\SQLsafeSQL Safe\Documentation).
Remote Backup Agent install fails when SQL Server is not installed
In order to install the SQLsafe SQL Safe Backup Agent remotely, the computer from which you install SQLsafe 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 SQLsafe 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 SQLsafe SQL Safe version 6.0 or later
In a FIPS-compliant environment, SQLsafe 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.
...
Due to the extensive TSM enhancements included in SQLsafe 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.
...
Users with 64-bit installations must follow different steps to install reports. For more information, see Idera solution 3891, "Where do I find the SQLsafe SQL Safe reports," in the knowledge base on Support (www.idera.com/support).
SQLsafe SQL Safe 4.0 users who upgrade to SQLsafe SQL Safe 7.1 or newer cannot use existing backup policies as part of new restore policies
SQLsafe SQL Safe 4.0 users who upgrade to SQLsafe 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 SQLsafeSQL Safe.
SQLsafe SQL Safe Management Service logging multiple grooming events per day
Some users may notice the SQLsafe SQL Safe Management Service logging multiple grooming events in the Windows Application log each day. SQLsafe SQL Safe should be logging only one such event per day.
...
Enabling the SE_MANAGE_VOLUME_NAME privilege for your SQL Server account improves general SQL Server file I/O performance as well as SQLsafe 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
SQLsafe 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 deleted the database if you experience this issue.
...
When you add a new drive to a server, you must restart the SQLsafe SQL Safe Filter Service to make sure that the SQLsafe SQL Safe Filter driver is attached to the new drive. When the SQLsafe SQL Safe Filter Service starts, it attaches the SQLsafe 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 SQLsafe SQL Safe Filter Service after adding any new drive.
...
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 SQLsafe SQL Safe Filter Service or the SQL Server Instance and then delete the files manually.
Offline SQLsafe SQL Safe Web Help may display a blank page
Some users experience a blank page when pressing F1 and using the offline SQLsafe SQL Safe Help. If this issue occurs, access the online version of SQLsafe SQL Safe 7.1 Help at http://www.idera.com/help/sqlsafeSQL Safe/7-1/web/default.htm.
SQLsafe SQL Safe Backup Agent may stop unexpectedly
The SQLsafe SQL Safe Backup Agent may stop unexpectedly and SQLsafe SQL Safe displays an error similar to, ".NET Runttime 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
SQLsafe SQL Safe may experience an issue when you attempt to import backup archive sets into your Repository.
Logins data archived only on Full backups
SQLsafe SQL Safe archives Logins data only when you perform a Full backup. SQLsafe 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.
...
The new granular alert notifications available in version 6.6 provide more detailed feedback about policy compliance and status. Because policy jobs created with SQLsafe 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 SQLsafe 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
SQLsafe SQL Safe is unable to generate SQL virtual database metadata for backups that use the following options:
...
InstantRestore appears to stall when restoring databases that contain read-only file groups
SQLsafe 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 deleted the database if you experience this issue.
...
When you add a new drive to a server, you must restart the SQLsafe SQL Safe Filter Service to make sure that the SQLsafe SQL Safe Filter driver is attached to the new drive. When the SQLsafe SQL Safe Filter Service starts, it attaches the SQLsafe 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 SQLsafe SQL Safe Filter Service after adding any new drive.
...
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 SQLsafe SQL Safe Filter Service or the SQL Server Instance and then delete the files manually.
...
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
...