Comments
Sort by recent activity
RBA wrote:
Hi Sebest1,
At the moment, SQL Backup 6 will not delete certain backups:
Version 5 files
Encrypted backups (unless the password is the same as the backup being made)
Backups of other databases
Backups of differing types (Full, diff, log)
Are any of the files not being deleted outside of the above? If so, please let me know the particulars.
Thanks
Robin
Robin -
Can you confirm that by "Backups of different types" you mean that as long as both my scheduled full and scheduled log backups are BOTH set to delete older than X days, and are BOTH pointed to the same folder, log and full backups will be deleted from the folder as intended?
Tim / comments
RBA wrote:
Hi Sebest1,
At the moment, SQL Backup 6 will not delete certain backups:
Version 5 files
Encrypted backups (unless the password is the same as the backup being made)
Backups of other d...
I'd like to know this too. I don't think you can, however. We've held off on rolling it out because it is a security risk that absolutely anyone can install the client and connect to the repository if they know the name. / comments
I'd like to know this too. I don't think you can, however. We've held off on rolling it out because it is a security risk that absolutely anyone can install the client and connect to the repository...
petey wrote:
Yes, it is indeed a bug, where SQL Backup 6 fails to identify encrypted files created by previous versions of SQL Backup for deletion.
This will be fixed in the next release of SQL Backup. Thanks for bringing this to our attention.
By next release, do you mean it was fixed in 6.1, will be fixed in the next release of 6.x, or that I will have to manually purge my files since it won't be fixed until version 7.x? / comments
petey wrote:
Yes, it is indeed a bug, where SQL Backup 6 fails to identify encrypted files created by previous versions of SQL Backup for deletion.
This will be fixed in the next release of SQL B...
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!