Page History
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
| Newtablink | ||||
|---|---|---|---|---|
|
Known issues for 7.4
- When a backup operation in SQLsafe is performed at the same time as the native SQL Server, the successful backup job on SQLsafe 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 Backup Agent to create policies on servers where the timezone has been changed may need to restart the SQLsafe Backup Agent service to update the timezone and ensure policies run on the correct schedules.
Previous known issues
SQLsafe Repository no longer supports SQL Server 2000
SQLsafe 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 no longer supports Itanium
SQLsafe 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 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 Maintenance wizard to modify, repair, or remove this version of SQLsafe must click Browse to select the current SQL Server hosting the Repository in the SQLsafe 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 6.5 or later
When some users upgrade to SQLsafe 6.5 or later, the backup file names using the %timestamp% macro may change. This issue affects users who have SQLsafe 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 6.5, %timestamp% expands to the local time of the backup. As a result, SQLsafe may write new backups to files already created by an earlier version of SQLsafe immediately after upgrading. By default, SQLsafe 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).
...