RE: Possible restore issue with 7.3.0.383 to replace database

April 3, 2013, 8:50 pm

≫ Next: use Operators Mailing instead of SQL Backup native mailing

I don't recall anything changed with regards to how the REPLACE function worked. The most important thing is getting the database logical names to match, and SQL Server handles the rest. Note that the following examples use native SQL Server backup/restore commands, and the results would be identical if you used SQL Backup commands.

E.g. this fails because the logical names in the backup set do not match that of the 'db2' database:

Code:

CREATE DATABASE db1 ON PRIMARY (NAME = 'db1_dat', FILENAME = 'f:\data\db1\db1.mdf') LOG ON (name = 'db1_log', FILENAME = 'f:\data\db1\db1.ldf')
GO
CREATE DATABASE db2 ON PRIMARY (NAME = 'db2_dat', FILENAME = 'f:\data\db2\db2.mdf') LOG ON (name = 'db2_log', FILENAME = 'f:\data\db2\db2.ldf')
GO
BACKUP DATABASE db1 TO DISK = 'f:\data\db1.bak'
GO
RESTORE DATABASE db2 FROM DISK = 'f:\data\db1.bak' WITH REPLACE
GO

This succeeds because we restored 'db2' from the 'db1' backup set, preserving the logical names:

Code:

DROP DATABASE db2
GO
RESTORE DATABASE db2 FROM DISK = 'f:\data\db1.bak' WITH MOVE 'db1_dat' TO 'f:\data\db2\db2.mdf', MOVE 'db1_log' TO 'f:\data\db2\db2.ldf', REPLACE
GO
RESTORE DATABASE db2 FROM DISK = 'f:\data\db1.bak' WITH REPLACE
GO

This also works because the logical names of both databases match.

Code:

DROP DATABASE db2
GO
CREATE DATABASE db2 ON PRIMARY (NAME = 'db1_dat', FILENAME = 'f:\data\db2\db2.mdf') LOG ON (name = 'db1_log', FILENAME = 'f:\data\db2\db2.ldf')
GO
RESTORE DATABASE db2 FROM DISK = 'f:\data\db1.bak' WITH REPLACE
GO

↧

use Operators Mailing instead of SQL Backup native mailing

April 4, 2013, 8:31 am

≫ Next: RE: Possible restore issue with 7.3.0.383 to replace database

≪ Previous: RE: Possible restore issue with 7.3.0.383 to replace database

hi everyone!

im totally new to SQL Backup. I'm currently playing with it and noticed that SQL Backup use is own mailing system.

I would like to know if its possible to configure SQL Backup to use the SQL Server mailing system instead. That way, it would use the Operators strategy that we have implemented there.

Is it possible?

thank you!

alex

↧

RE: Possible restore issue with 7.3.0.383 to replace database

April 4, 2013, 11:32 am

≫ Next: RE: Possible restore issue with 7.3.0.383 to replace database

≪ Previous: use Operators Mailing instead of SQL Backup native mailing

Pete,

Here is what I did.

I created the new database under E:\applctn\ahah\devl\database with 3 files, SYS/DATA_001 and LOG_001. This is in SQL2012 running on W2K12. I had a backup taken using SQLBackup 7.1 in SQL2005 on W2K3R2 of the prod database where it resides under D:\applctn\ahah\prod\database with the same 3 files, SYS/DATA_001 and LOG_001. The backup creates two files to speed the process up.

I copied the 2 backups files to the W2K12 server. When I tried to run the script it failed because it tried to restore to D:\applctn\ahah\prod\database. Once I put the moved statements in it worked fine and replaced the original databases I had created. I had this happen to another database under the same circumstances. This made me believe that maybe the restore from script had looked at the backup files for its location information rather than the master DB locations.

We do lots of restored from production backups to at and dev servers where the file locations differ from the original ones and the script works fine. It gets its location information from the master DB rather than the backup file itself.

Can you check this out please?

Thanks

Chris

↧

RE: Possible restore issue with 7.3.0.383 to replace database

April 4, 2013, 11:48 pm

≫ Next: RE: Possible restore issue with 7.3.0.383 to replace database

≪ Previous: RE: Possible restore issue with 7.3.0.383 to replace database

You are right, SQL Server 2012 seems to have a different behavior with regards to restoring over an existing database.

In SQL Server 2005 and 2008, you could overwrite an existing database, and have the existing database's data files (whose logical names match those in the backup set) replaced by those in the backup set, using the REPLACE option.

In SQL Server 2012, this is no longer the case. SQL Server 2012 insists on placing the data files in their original location, unless the existing database was originally restored from a backup of the same database.

In your case, you would need to first restore the dev database from a backup of the production database, using the MOVE options. After that, subsequent restores can be performed without the need for the MOVE options.

If it's any consolation, SQL Backup 7.3 can help somewhat with the MOVE options. If all the data files and trx log files can be grouped in the same folders, you can use the MOVE DATAFILES/LOGFILES shortcut e.g.

Code:

EXEC master..sqlbackup '-sql "RESTORE DATABASE ahah_devl FROM DISK = [...] WITH MOVE DATAFILES TO [E:\applctn\ahah\devl\database\data\], MOVE LOGFILES TO [E:\applctn\ahah\devl\database\log\]"'

There is also MOVE FILESTREAMS ... for filestreams, and MOVE FULLTEXTCATALOGS ... for full text catalogs.

↧

RE: Possible restore issue with 7.3.0.383 to replace database

April 5, 2013, 8:18 am

≫ Next: RE: use Operators Mailing instead of SQL Backup native mailing

≪ Previous: RE: Possible restore issue with 7.3.0.383 to replace database

Thanks for the update.

That is really interesting. I will certainly test out the MOVE DATAFILES and MOVE LOGFILES options.

I now need to ask this further question. We will be using AlwaysOn Availability Groups. The thinking is this currently. We have a database on say the dev server, in a different location than the prod backup. We take the dev database out of the availability group and then restore the prod backup to both server A with recovery and to server B with norecovery. Then put the databases back into the availability group.

Based on what you have said and I saw I need the MOVE statements this first time. Now this stays the same for a few days and we start taking backups, on the node that the availability group allows. Now we have to perform another restore from prod to dev. Will I still need the MOVE or will SQL2012 remember where the databases reside on dev and I can restore without the MOVE?

Thanks

Chris

↧

RE: use Operators Mailing instead of SQL Backup native mailing

April 5, 2013, 9:22 am

≫ Next: SQL error 15157: Setuser failed...

≪ Previous: RE: Possible restore issue with 7.3.0.383 to replace database

Unfortunately the tool does not currently have this capability
You can request features for this product in our uservoice forums
https://sqlbackup.uservoice.com/forums/91737-sql-backup-
These forums are actively monitored by our development team and allow our users to request features and vote on them.
If a feature receives a significant amount of votes or is deemed to have merit development may include the feature in a future release.

↧

SQL error 15157: Setuser failed...

April 5, 2013, 10:09 am

≫ Next: Wrong information in the Activity History & Activity Propert

≪ Previous: RE: use Operators Mailing instead of SQL Backup native mailing

hi everyone!

i'm using SQL Backup 7.3.0.57 with SQL Server 2012. If i try to backup a database with local and network copy, it work but if i schedule a backup with the same options, i get an error message:

Quote:

SQL error 15157: Setuser failed because of one of the following reasons: the database principal 'domain\backupserviceaccount' 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.

I tried the solution of adding the SkipChecks key to the BackupSettingsGlobal(local) registry node explained here http://www.red-gate.com/messageboard/viewtopic.php?t=9343&highlight=skipchecks but it didnt worked.

To make it work, i had to put the SkipChecks key to the namedInstance inside the BackupSettingsGlobal node.

So here's my questions:

1. Is there a reason why the SkipChecks in the root of BackupSettingsGlobal don't work here?

2. Why do we have to do that? I didnt find any documentation that tell us that scheduled backup use the SQL Agent Service account instead of the SQL Backup Agent service account. What is the purpose of this check and why do we need to skip it to solve this? Is it a bug? a feature?

thank you for the help!

↧

Wrong information in the Activity History & Activity Propert

April 5, 2013, 10:27 am

≫ Next: RE: use Operators Mailing instead of SQL Backup native mailing

≪ Previous: SQL error 15157: Setuser failed...

hi!

i'm using SQL Backup 7.3.0.383 with SQL Server 2012. When i do my FULL backup of 3 databases with local & network copy, i get wrong informations (check the images at the end of the post).

1. The first database to backup doesnt have the icon telling me that there's a network copy of the file. The second and third database have the icon.
2. If i check the properties of my 2 databases activity that has the network icon, it tell me that "Copy To Network" failed!

in fact, everything has worked great. All my files are on the network so i don't understand why there's so mismatch information in the GUI.

[img]https://skydrive.live.com/redir?resid=341A82DB0B91EDD9!511&authkey=!AKo1SZ-vSzfsseI[/img]
[img]https://skydrive.live.com/redir?resid=341A82DB0B91EDD9!510&authkey=!ADaFX6duIi9AD9A[/img]

Also, if the network copy has not worked, it still telling me that the job has been Successful. So obviously, there's a problem with the way the GUI show us the information!

thank you for the help!

alex

↧

RE: use Operators Mailing instead of SQL Backup native mailing

April 5, 2013, 10:38 am

≫ Next: RE: SQL error 15157: Setuser failed...

≪ Previous: Wrong information in the Activity History & Activity Propert

thank you.
I have created a feature request for that: http://sqlbackup.uservoice.com/forums/91737-sql-backup-/suggestions/3818324-use-sql-server-native-operators-mailing-instead-of

alex

↧

RE: SQL error 15157: Setuser failed...

April 7, 2013, 5:49 pm

≫ Next: RE: Possible restore issue with 7.3.0.383 to replace database

≪ Previous: RE: use Operators Mailing instead of SQL Backup native mailing

Quote:

1. Is there a reason why the SkipChecks in the root of BackupSettingsGlobal don't work here?

SkipChecks needs to be in an instance's node. The link you referred to mentions the same thing i.e.

1. Using Regedit navigate to the following Registry Folder:
HKEY_LOCAL MACHINE\Software\Red Gate\SQL Backup\BackupSettingsGlobal\(LOCAL) or <SQL Instance Name>

Quote:

2. Why do we have to do that? I didnt find any documentation that tell us that scheduled backup use the SQL Agent Service account instead of the SQL Backup Agent service account. What is the purpose of this check and why do we need to skip it to solve this? Is it a bug? a feature?

The SQL Backup Agent service account has to have SQL Server sysadmin rights in order to perform backups and restores. However, we did not want to allow any account that has rights to run the SQL Backup extended stored procedures (sqlbackup) to be able to back up and restore any database they wanted. We wanted to follow the rights already set up in SQL Server for that account i.e. if user A has only backup rights to databases A and B, they should only be able to back up those databases, and not any other databases.

Thus, when you run the sqlbackup extended stored procedure, SQL Backup will first check the backup/restore rights of the logged on user account running the stored procedure. If that account is a SQL Server sysadmin, no further checks are made. Otherwise, it uses the SETUSER function to impersonate the logged on user account. Unfortunately, this procedure sometimes fails due to an issue known as 'double hop authentication', and has to do with how user security is set up on your Windows domain. You can google for more details on this.

You could set up your SQL Server Agent service to run using an account that's a SQL Server sysadmin to address this issue. However, as that's not always feasible from a security viewpoint, SkipChecks was introduced as another work around. Basically, it tells SQL Server to skip the part where it checks if the logged-on user account has rights to back up and restore the specified databases. You can do this if everyone that has rights to run the sqlbackup extended stored procedure is allowed to back up and restore any database on your SQL Server instance.

↧

RE: Possible restore issue with 7.3.0.383 to replace database

April 7, 2013, 6:08 pm

≫ Next: RE: Wrong information in the Activity History & Activity Propert

≪ Previous: RE: SQL error 15157: Setuser failed...

I think you would not need to use the MOVE options, since the database you are overwriting was originally restored using backups from the same database whose backup sets you are now using to restore from.

From what I can tell, as long as the database you are trying to restore over, and the backup set you are using to restore from, have the same family GUID value, SQL Server will use the file locations of the database you are now overwriting.

I don't know how to find out the family GUID value of an active database, but if you back up that database, you can read this value using the RESTORE HEADERONLY command.

↧

RE: Wrong information in the Activity History & Activity Propert

April 8, 2013, 5:18 am

≫ Next: RE: Wrong information in the Activity History & Activity Propert

≪ Previous: RE: Possible restore issue with 7.3.0.383 to replace database

Hi Alex,

Thank you for raising this. This is a known issue in SQL Backup 7.3 (reference SB-5459) whereby the result of copying a backup to a network share is not reported correctly in the Activity History and Backup Properties if the VERIFY option is also applied to the backup. When backing up multiple databases with both these options (COPYTO and VERIFY), the results of copying the backup to a network share are not reported for the first database in the set.

I'm very sorry for the confusion this is causing you. We are currently working on the next release of SQL Backup, which will replace the installer. This bug should be addressed in a subsequent release of SQL Backup.

I hope that helps. Please get in touch if you need more information.

Thanks,

Marianne

↧

RE: Wrong information in the Activity History & Activity Propert

April 8, 2013, 5:47 am

≫ Next: RE: Use of file location tags in "Copy backup to network locatio

≪ Previous: RE: Wrong information in the Activity History & Activity Propert

Hi Mto

Thank you for your forum post and sorry that you have encountered a problem.

I will deal with your latter comment first:

Quote:

Also, if the network copy has not worked, it still telling me that the job has been Successful. So obviously, there's a problem with the way the GUI show us the information!

This has always been the case, failure to copy the sqb file created from the path specified in the TO DISK arguement to path specified in COPYTO keyword is not a reason to fail the backup. The backup was still successfully created. However SQL Backup should report successful backup with warnings when the COPYTO phase failed, by placing a yellow triangle icon in the Outcome field.

Now to the main problem:

Quote:

When i do my FULL backup of 3 databases with local & network copy, i get wrong informations (check the images at the end of the post).

1. The first database to backup doesnt have the icon telling me that there's a network copy of the file. The second and third database have the icon.
2. If i check the properties of my 2 databases activity that has the network icon, it tell me that "Copy To Network" failed!

in fact, everything has worked great. All my files are on the network so i don't understand why there's so mismatch information in the GUI.

The help information is as follows:

Quote:

In the fourth column, indicates that the option to copy the backup to a network location was selected. The Outcome column indicates whether this was successful.

Outcome shows the results of the backup or restore operation. An icon is displayed so that you can scan the list easily.

So if I have understood correctly the first database that you highlighted in your first screen shot listed, in fact had a successful COPYTO action despite the being no icon to indicate that a COPYTO action had taken place in the 'Copy to Network' column?

The remaining two databases have the Copy To Network icon to indicate that the COPYTO keyword was selected but the copy process failed and therefore should have included a yellow warning triangle icon in the outcome column?

A support call has been created for you, the support call reference number is F0071480. Can you please send an e-mail to support@red-gate.com with a copy of the SQL Backup log file for this job? Please include the above call reference number in the subject field of the e-mail. To obtain the requested log file, select the required entry in the Activity History, right click and select show log. The log information will appear, copy and paste the contents.

Just in case the problem is a GUI refresh problem, please follow the steps below to clean out the SQL Backup GUI Activity Cache:

Many Thanks
Eddie

↧

RE: Use of file location tags in "Copy backup to network locatio

April 8, 2013, 5:59 am

≫ Next: RE: Wrong information in the Activity History & Activity Propert

≪ Previous: RE: Wrong information in the Activity History & Activity Propert

It doesnt seem like I can use multiple file location tags when specifiying a path. Am I doing something wrong?

Here is what I specified:

P:\MMurphy Test\<DATETIME yyyy>\<DATETIME mm>\<DATETIME dd>\DataHubPomerene
Here is what I got:

P:\MMurphy Test\2013\<DATETIME mm>\<DATETIME dd>\DataHubPomerene
I got an error when it tried to backup the database to the path above.

↧

RE: Wrong information in the Activity History & Activity Propert

April 8, 2013, 6:47 am

≫ Next: Issue with 7.3

≪ Previous: RE: Use of file location tags in "Copy backup to network locatio

Further to my previous post I can now confirm that this is a bug, reported in Bug Report SB-5459. I will update this forum topic when a fix for this issue becomes available.

Many Thanks
Eddie

↧

Issue with 7.3

April 8, 2013, 6:52 am

≫ Next: RE: Issue with 7.3

≪ Previous: RE: Wrong information in the Activity History & Activity Propert

We upgraded to 7.3 last week although even though we aren't using the cloud part.

The problem we're having is that it takes forever to show the activity history. I have 2 instances defined in the application. When I open it, it looks fine. If I expand the instance to show the databases, I get the spinny thing and takes 45 minutes plus to load the activity history. It's the same if I attempt to restore as the dialog takes the same amount of time to display what can be restored.

There's only 20 databases on the one instance I was working with. It never took this long before the upgrade. Any advice? Can we roll back to 7.2?

↧

RE: Issue with 7.3

April 9, 2013, 11:29 am

≫ Next: RE: Issue with 7.3

≪ Previous: Issue with 7.3

Sorry you are experiencing this.
It appears you are running into a known issue with 7.3 and the activity history which has been reported by several users.
Some users have seen slightly increased performance by Reducing the amount of data in the activity cache.
http://www.red-gate.com/supportcenter/content/SQL_Backup/help/7.2/SBU_ActivityCacheLocation
This issue is currently under investigation and we plan to release a fix once one becomes available.

If you wish to downgrade to a previous version you can find the installer here.
ftp://support.red-gate.com/patches/SQLBackup/04Sep2012/SQLBackup_7.2.0.286.zip

↧

RE: Issue with 7.3

April 10, 2013, 8:59 am

≫ Next: RE: Issue with 7.3

≪ Previous: RE: Issue with 7.3

I am trying to restore and experiencing the same issue. I have 3 instances defined and the spinning thing has been going for more than 30 minutes and still running once I click the Restore button.

I checked
http://www.red-gate.com/supportcenter/content/SQL_Backup/help/7.2/SBU_ActivityCacheLocation

as suggested and %LOCALAPPDATA%\Red Gate\SQL Backup\Server Data\localDataCache.dat is only 38KB and 1.dat-journal is only 11KB. These are the only 2 files that has today's date modified.
As for "Reducing the amount of data in the activity cache", we have a SQL job that deletes the server backup history that is older than 30 days.

I'm just glad I'm not trying to urgently restore this db. I'm glad it's a test restore to make sure the backup is good.

Just wondering if the spinning thing will ever stop and the activity history will actually come up? And if so, how long did it took?

↧

RE: Issue with 7.3

April 10, 2013, 9:30 am

≫ Next: Test restore jobs have started failing.

≪ Previous: RE: Issue with 7.3

Hi,

We're looking into why the cache synchronisation is slow for a number of users. If you need to restore and the UI is unresponsive a t-sql script can be used instead.

If the green spinner completes, is it faster from then on or always slow on refresh? We were anticipating a slightly longer duration immediately after upgrade but not on every refresh. If its permanently slow, you can delete the local cache files on the workstation and the data.sdf on the server which will clear history information (the activity history will still show previous backups made using SQL Backup, but Red Gate specific additional information for old backups will be lost).

Regards,

↧

Test restore jobs have started failing.

April 10, 2013, 9:37 am

≫ Next: RE: Issue with 7.3

≪ Previous: RE: Issue with 7.3

I've had several scheduled jobs running for months to do a weekly test restore and run DBCC checks on the restored db's. In the last two weeks the jobs have all started failing with this error message:

SQL Backup failed with exit code: 790 SQL error code: 3257 [SQLSTATE 42000] (Error 50000). The step failed.

SQL Backup 7.0.3.2 is installed, I"m updating that to 7.3 right now.

SQL Backup is installed on a Windows Server 2008 VM running on an ESX host (servername = PLUTO). SQL Server 2008 R2 is installed there, also. It manages backups on three SQL servers on the network (srvernames MARS, UTAH and SONORA). Everything is SQL Server 2008 R2. All backups are done locally to their resident servers, then archive copies are copied to three other locations, one off site. The job that were working fine restored the latest backup from four enterprise critical apps (2 on SONORA and 2 on MARS) to the SQL Server instance on PLUTO, the server that hosts SQL Backup. The successful backups then ran the full set of DBCC checks.

The SQL Backup log files I can find are empty, but I don't find them at exactly the path specified in the docco. Where should the logs be on a Windows Server 2008 R2 64-bit machine?

↧

Latest Images