User profile for jhboricua

The referenced thread dates back to 2009 and there's still no fix yet from Red Gate? Seriously? / comments

The referenced thread dates back to 2009 and there's still no fix yet from Red Gate? Seriously?

0 votes

So I got this working now. When examining the logs I saw the following on the failed backup jobs: "SQL Backup could not access [HKEY_LOCAL_MACHINESOFTWARERed GateSQL BackupBackupSettingsGlobal(LOCAL)] running as user [svcRedGate]." So I had to give the service account that runs the SQL Backup Agent account {svcRedGate] permissions to the registry keys at [HKEY_LOCAL_MACHINESOFTWARERed GateSQL BackupBackupSettingsGlobal(LOCAL)]. Then I tried to run a backup again and it failed with: "Warning 402: Failed to open local data store: Access to the database file is not allowed. [File name=D:Red GateSQL BackupData(local)data.sdf]" Apparently the service account didn't have permissions set here either, to Regdate's OWN FILES!!! Again, I gave the service account that runs the SQL Backup Agent service permissions to the Red Gate directories. After doing this, backups were successful. I can now also browse the network share for restores, which pretty much confirms to me this was NEVER a share permission issue but missing permissions on RedGate's end. I then asked the support technician I was working with why were this permissions missing in the first place? During the install I was asked both for the path where I wanted the tool installed and also under what account I wanted the Backup Agent service to run and I provided that info. So, why didn't the installer grant the account the permissions it NEEDED for the tool to work in the first place? This is the response I received: In regards to this situation, I definitely understand your frustration, and how challenging it was for you to properly set up the permissions to get the software running correctly. But ultimately, the way our tool handles permissions is a design decision. The majority of our customers prefer to have that granularity and control to configure permissions within their environment, for the sake of security (even though it is laborious). In a "locked down" environment where there are intentionally multiple layers of permissions for security reasons, it would be concerning if a 3rd party tool can easily and automatically bypass these various layers. At the end of the day, it is going to be hard for us to meet everyone's needs. As you can see from the forum posts, there are definitely users who feel the same way as you (regarding this particular issue), but we would suspect that there would be an even larger and more critical backlash if we were to have "an automated permission handling". I personally find the explanation to be absurd and, in my opinion, I see this as a design flaw, pure and simple. There's nothing about this that speaks security when the tool functionality is BROKEN unless I manually do the steps above. Back when we were doing SQL backups via Commvault, I didnâ€™t have to manually give the account that runs the Commvault service permissions to the Commvaultâ€™s directory so it could read its own files or to the Commvault registry keys so it could access its own settings. Commvault handled that itself when it was installed. All I had to make sure was that the service account had permissions to the final destination of the backup files. When doing SQL backups natively via SQL, I donâ€™t have to give the SQL Agent service account permissions to the directory where the SQL binaries are nor I have to give it permissions to the SQL registry keys. All those are handled by the installer when I specified the service accounts and paths. All I have to make sure, again, is that the service account has permissions to the final destination of the backup files. The ONLY time I've had to mess with an application in this manner has been because the application was either poorly designed or it's an ancient app that was not designed with modern Windows systems in mind. Which in both cases mean they didn't follow MS design best practices for applications, especially in regards to security. These are the apps that want to run under elevated rights (think local admin credentials) in order to work. So, in order mitigate risk and not have them run with elevated rights, we end up having to mess with manually assigning permissions to regkeys and directories/files. In my mind, there's no excuse for a modern application such as RedGate Backup Pro to require this level of meddling. /end rant / comments

So I got this working now. When examining the logs I saw the following on the failed backup jobs: "SQL Backup could not access [HKEY_LOCAL_MACHINESOFTWARERed GateSQL BackupBackupSettingsGlobal(LOCA...

0 votes

Crap, you're right. Since it was a new instance I had not setup the backup jobs yet because I first was trying to restore the database for the application we're trying to migrate. But I just looked at the job we setup for backing up the system databases, which also writes to the same network share and it is also failing. / comments

Crap, you're right. Since it was a new instance I had not setup the backup jobs yet because I first was trying to restore the database for the application we're trying to migrate. But I just looked...

0 votes

Unable to restore from network share - Server 2012/SQL 2012

I just installed the latest SQL Backup on a new Server 2012 R2 Server running SQL 2012 Standard last week. I've created the Multi-String registry key 'BrowsingUserList' just like I've done so many ...

3 followers 4 comments 0 votes

SQL Backup 7.4 fresh install not detecting SQL cluster

When I run the setup file from the active node of a SQL cluster, in this case a SQL 2008 R2 cluster running on Server 2008 R2 Enterprise, the installer fails to detect that it's on a cluster. I don...

1 follower 1 comment 0 votes

Hi Smiley, I while back I had to write a script to restore a bunch of databases. The backups were SQL Backup files. I blogged about it, you could use/adapt it to your needs. Hope it helps: http://sysadmingrunt.blogspot.com/2011/ ... ll_23.html / comments

Hi Smiley, I while back I had to write a script to restore a bunch of databases. The backups were SQL Backup files. I blogged about it, you could use/adapt it to your needs. Hope it helps:http://sy...

0 votes

If I have to guess, you are probably having a different issue that has nothing to do with SQL Backup. The first thing you need to do is verify that you can connect to the SMTP server from the SQL box. Have you done this with say... Putty or the Telnet command connecting to port 25 on the SMTP server? http://technet.microsoft.com/en-us/libr ... v=exchg.65).aspx If the test fails, then you need to start your troubleshooting there and take SQL Backup out of the equation. It could be the Windows Firewall on either server blocking the connection, or a setting on the SMTP service not allowing relaying or a network device in the path not allowing the connection. / comments

If I have to guess, you are probably having a different issue that has nothing to do with SQL Backup. The first thing you need to do is verify that you can connect to the SMTP server from the SQL b...

0 votes

If you're not squeamish about scripting, you could wrap everything into a powershell script that does: 1. Backup using Redgate SQL Backup. 2. Copy files after backup is complete. 3. Do the pruning of older files from the network share. I use a powershell script for #3 as I found that having the SQLBackup utility doing this was unreliable. / comments

If you're not squeamish about scripting, you could wrap everything into a powershell script that does: 1. Backup using Redgate SQL Backup. 2. Copy files after backup is complete. 3. Do the pruning ...

0 votes

Angela, I would strongly suggest that you add a disk dependency on the SQLBackupAgent generic cluster service in cluster administrator. See this thread for reference: http://www.red-gate.com/MessageBoard/vi ... hp?t=13361 When you install SQLBackup on a cluster the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\SQL Backup\BackupSettingsGlobal\(LOCAL) is populated with the path of the shared cluster disk you specified during install. There is an issue where if the cluster service for SQLBackup tries to start before the disk resource is online (like during a failover or a reboot), the key will get reset with a local path on the node, effectively wiping the backup history and timeline from the SQLBackup GUI. By adding the disk dependency you'll ensure the service won't attempt to start before the shared disk becomes available. / comments

Angela, I would strongly suggest that you add a disk dependency on the SQLBackupAgent generic cluster service in cluster administrator. See this thread for reference:http://www.red-gate.com/Message...

0 votes

Hi Linda, Please confirm, does right clicking the clustered SQL server in the SQL Backup GUI deactivates the license on both the active AND passive node? / comments

Hi Linda, Please confirm, does right clicking the clustered SQL server in the SQL Backup GUI deactivates the license on both the active AND passive node?

0 votes

How can we help you today?

jhboricua

Activity overview