Comments
Sort by recent activity
Thanks - 6.3 isn't bad at all.
Tim / comments
Thanks - 6.3 isn't bad at all.
Tim
Brian Donahue wrote:
Hi Jonathan,
We have had several reports of the extended stored procedure not being freed by SQL Server, which is expected on a small number of installations. This most likely will happen on SQL Server 2000. However, repeated attempts to run the upgrade wizard do seem to solve the problem. We don't have a firm explanation for why it would work on the second or third attempt.
Brian -
I had the same issue on 3 SQL 2005 servers. Finally gave up and did the install manually using the executable. This worked.
Tim / comments
Brian Donahue wrote:
Hi Jonathan,
We have had several reports of the extended stored procedure not being freed by SQL Server, which is expected on a small number of installations. This most likel...
Emails DO NOT OBFUSCATE for restores created as a scheduled task manually on the server. The emails for backup jobs, all created via the gui, are obfuscated. It also appears that emails sent when the restore is created via the gui also do obfuscate.
So - emails sent when a restore job is performed via the gui are fine. Emails sent when a restore job is run via a sql agent job, are NOT fine.
Since scheduled restores are still not available via the gui (hint hint) we have to do it via agent jobs. This is a significant part of our workflow and can't be changed. At this point, I am looking at turning off the emails, but will involve some serious discussion with others above me since it means no awareness of the job outcome. This is a VERY serious issue...
Tim / comments
Emails DO NOT OBFUSCATE for restores created as a scheduled task manually on the server. The emails for backup jobs, all created via the gui, are obfuscated. It also appears that emails sent when t...
We ARE using the MAILTO option. SQL is not sending the email, Redgate is. Thus, it should be working.
I can understand that scheduled restores may not be implemented immediately. However, I need a solution to the plain text password issue, as its clearly a bug since MAILTO should be encrypting it.
here is the actual command being run as a scheduled job in SQL (I've removed any identifiable information) -
EXECUTE master..sqlbackup N'-SQL "RESTORE DATABASE [DB_test] FROM DISK = ''\\path\to\my\share\Mirror\full_backup.sqb'' WITH RECOVERY, MAILTO = ''me@mydomain'', MOVE ''DB_Test_data'' TO ''D:\MSSQL.1\MSSQL\Data\DB_Test.mdf'', MOVE ''DB_Test_log'' TO ''D:\MSSQL.1\MSSQL\Data\DB_Test.ldf'', PASSWORD = ''HNFSD&^#JMMKJ'', REPLACE"' / comments
We ARE using the MAILTO option. SQL is not sending the email, Redgate is. Thus, it should be working.
I can understand that scheduled restores may not be implemented immediately. However, I need a ...
priyasinha -
The problem with this is that the password is also sent clear text in EMAILS, which is a HUGE problem. I actually didn't catch this until now. I understand some of what you are saying, although I still disagree because nothing should ever be sent in clear text over the network. In discussion here, we all agreed that the solution is a form of public/private key - require a key in order to do a restore.
That being said, passing the password in clear text in the emails is a disaster - it can't be kept secure unless we start encrypting the entire channel. / comments
priyasinha -
The problem with this is that the password is also sent clear text in EMAILS, which is a HUGE problem. I actually didn't catch this until now. I understand some of what you are saying,...
Since I have your ear, any idea if I can encrypt the password in the restore job in v6? I understand putting this functionality back into the product (it was removed at some point in the past) is was/is being considered.
Thanks!
Tim / comments
Since I have your ear, any idea if I can encrypt the password in the restore job in v6? I understand putting this functionality back into the product (it was removed at some point in the past) is w...
Thanks! / comments
Thanks!
Peter -
Thanks, we are keeping emails, but I didn't realize that the backup history in the compact edition database is also kept in MSDB. That's really good to know, since it is easily queried.
As far as the backup history and purging goes, we purge our backups after 35 days. However, we write to a network share directly, not locally, and the share is backed up also. The tapes are kept for a year, so even if the file doesn't exist on the share, it can be retrieved from tape if needed.
Tim / comments
Peter -
Thanks, we are keeping emails, but I didn't realize that the backup history in the compact edition database is also kept in MSDB. That's really good to know, since it is easily queried.
As ...
Same problem here - my gui is almost unusable. It fails to load the activity history for 30+ minutes, and selecting backups is almost as bad. I am at my wits end, and ready to switch to a new product. / comments
Same problem here - my gui is almost unusable. It fails to load the activity history for 30+ minutes, and selecting backups is almost as bad. I am at my wits end, and ready to switch to a new product.
Peter -
If we do purge old entries, how can we prove that a backup was done on a particular day? Is there a way to restore the old entries, or dump them to an archive database/file/etc? I have a mandate from management that I be able to prove backups were taken on a particular day, so I can't just purge old entries.
Also, I should note that I agree with the poster above who commented that if Red Gate back-ended to a better database (SQL Server, perhaps) performance would probably be a LOT better.
Thanks
Tim / comments
Peter -
If we do purge old entries, how can we prove that a backup was done on a particular day? Is there a way to restore the old entries, or dump them to an archive database/file/etc? I have a ma...