Comments
Sort by recent activity
If I'm restoring a backup to a second (target) database, why does it care that the full-text catalog of the first (source) database is in use by the first database? Shouldn't it be creating a second full-text catalog as a part of the target database? / comments
If I'm restoring a backup to a second (target) database, why does it care that the full-text catalog of the first (source) database is in use by the first database? Shouldn't it be creating a seco...
You're right, the login account used by SQL Backup Agent didn't have rights to write to the Registry. Once I changed that (and restarted the service), applying those changes created the registry hierarchy under HKEY_LOCAL_MACHINE\SOFTWARE\SQL Backup\ (and not the Wow6421node tree).
Yes, it'd be nice if the GUI would complain on failure (save someone else the headscratching) :-) but pretty low on the urgency scale. / comments
You're right, the login account used by SQL Backup Agent didn't have rights to write to the Registry. Once I changed that (and restarted the service), applying those changes created the registry h...
On this server, there is no registry directory at: HKEY_LOCAL_MACHINE\SOFTWARE\SQL Backup\BackupSettingsGlobal
Under HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\Downloads\SQL Backup there is only a directory named 6
Under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Red Gate\SQL Backup there is a directory named BackupSettingsGlobal, and beneath it a directory (LOCAL), but only a small subset of the keys I expected to see defined there actually exist, BackupFileName being among the list of those missing. / comments
On this server, there is no registry directory at: HKEY_LOCAL_MACHINE\SOFTWARE\SQL Backup\BackupSettingsGlobal
Under HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\Downloads\SQL Backup there is only a direct...
Sorry, I listed the wrong version: 6.4.0.1012 (beta) / comments
Sorry, I listed the wrong version: 6.4.0.1012 (beta)
There's no other way to validate a backup after the fact?
The extended stored procedure isn't very user friendly, given that the file name isn't simple (with timestamp encoding) and might reside on a network share. [image] Might I suggest this as an enhancement for a future release?
For a quick validation of a single backup, it'd be really nice as a rt-click option under Activity History.
:idea: Actually, for my purposes (validating a subset of last night's backups), it's probably more efficient to query SQLBackupReportingDatabase for a set of databases and their associated filenames and pipe those to the stored procedure you described.
USE [SQLBackupReportingDatabase]
SELECT dbname, name
FROM backupfiles bf
JOIN backuphistory bh ON bf.backup_id = bh.id AND bf.server_id = bh.server_id
JOIN backuplog bl ON bh.id = bl.backup_id AND bh.server_id = bl.server_id
JOIN identities i ON i.id=bf.server_id
WHERE {criteria of your choice} / comments
There's no other way to validate a backup after the fact?
The extended stored procedure isn't very user friendly, given that the file name isn't simple (with timestamp encoding) and might reside on...
Sorry, I left out a step in that reinstallation sequence:
After running SQBServerSetup.exe, I renamed SQBCoreService.exe to SQBCoreService_release and copied the 6.4.0.1012 version in its place as SQBCoreService.exe (and restarted the service). / comments
Sorry, I left out a step in that reinstallation sequence:
After running SQBServerSetup.exe, I renamed SQBCoreService.exe to SQBCoreService_release and copied the 6.4.0.1012 version in its place as ...
SQL Backup Agent is unexpectedly using SqlSvc as its log on account (rather than .\wilcomp_sql as listed in the service properties). I confirmed this by creating a new SQL login, EWHSERVER801\SqlSvc (Windows Authentication, sysadmin) - SQL Backup now works, both for manual backups and scheduled backups!
This has to be an anomaly involving Win2008 - my Win2003 servers do not require this login to exist, and they're running SQL Backup just fine without it.
So this looks "fixed" (or at least "worked around"), but unexplainedly so. / comments
SQL Backup Agent is unexpectedly using SqlSvc as its log on account (rather than .\wilcomp_sql as listed in the service properties). I confirmed this by creating a new SQL login, EWHSERVER801\SqlS...
I've just installed 6.4.0.1012 and I'll retest with it.
Prior to your post I made another change that seems to have helped (though I'm never quite sure what triggers the failure) - I uninstalled the service and reran SQBServerSetup.exe, this time using the same Windows login for both Service Application Startup Account and SQL Server Authentication (previously I used SQL Authentication and a second SQL login for SQL Server Authentication). / comments
I've just installed 6.4.0.1012 and I'll retest with it.
Prior to your post I made another change that seems to have helped (though I'm never quite sure what triggers the failure) - I uninstalled th...
For all but one of my servers, reinstalling 6.4.0.56 using Windows authentication (rather than SQL Server authentication) resolved the service crash.
Only one of my servers is running Win2008 "classic" (the rest are either Win2008 R2 or Win2003). On this one box, installing the beta service (6.4.0.1012) seems to have resolved the service crash. However, scheduled backups still fail, in a manner that sounds rather like the temporary profile issue.
Running a manual backup of a database via the GUI works fine; running a scheduled backup of the same database fails. The two errors it reports are:
Error 800: BACKUP DATABASE permission denied in database: (ACA_CA)
SQL error 15157: Setuser failed because of one of the following reasons: the database principal 'EWHSERVER801\Sqlsvc' does not exist, its corresponding server principal does not have server access, this type of database principal cannot be impersonated, or you do not have permission.
When installing 6.4.0.1012 I made quite sure that Sqlsvc was not used - I stopped the 6.4.0.56 service, unintalled both SQL Backup packages (GUI and server components), rebooted the server, reinstalled SQL Backup and manually ran SQBServerSetup.exe, specifying Windows login EWHSERVER801\wilcomp_sql, then choosing Windows authentication (not SQL Server authentication) for step 2.
So why is it still making reference to EWHSERVER801\Sqlsvc? Is this a symptom of the temporary profile issue? If so, how to I check for such a profile (and remove it if it exists)? / comments
For all but one of my servers, reinstalling 6.4.0.56 using Windows authentication (rather than SQL Server authentication) resolved the service crash.
Only one of my servers is running Win2008 "clas...