Comments
Sort by recent activity
MasterCephus wrote:
ok, all of my backup files are set to that as you said...but how do I automatically turn that off? That seems like a pretty rough manual process to have to go in there every day and uncheck the newly created backup files so they will be deleted when I want them to be deleted.
There is no way (that I know of) to prevent Windows from setting this flag when a file is created or modified.
However, you can run a command to remove that flag on an entire directory and all its subdirectories. Just put the following command in a batch file and run it on your desired schedule: attrib -A D:\DatabaseBackups\*.* /S /D
Mike / comments
MasterCephus wrote:
ok, all of my backup files are set to that as you said...but how do I automatically turn that off? That seems like a pretty rough manual process to have to go in there every...
MasterCephus wrote:
If that's right (which I am not doubting you, just talking out loud), then there is no way to naturally delete the local files that you create...so the FILEOPTIONS flag is meaningless without doing something manually...
I agree. I don't think that should be the proper behavior for the ERASEFILES Option. It should be left up to the User on how to keep/erase/backup etc the backup files according to their needs and/or requirements.
I just use a separate scheduled batch file job to delete the local files. Not the best option, but it works! Hopefully, RedGate will look into changing this functionality in future versions of the SQL Backup product.
Mike / comments
MasterCephus wrote:
If that's right (which I am not doubting you, just talking out loud), then there is no way to naturally delete the local files that you create...so the FILEOPTIONS flag is me...
MasterCephus wrote:
ok Setting FILEOPTIONS = 3 didn't work...in fact it didn't delete on local disk and on the network...
By reading what the FILEOPTIONS flag does, I have to think this has to be a bug...
If I set it to 1, it will delete the files from the network. Tonight I will run a backup with the flag set to 2 to see if it deletes the files from disk. If that works, then there should be no reason that 3 would not do both (from what the help file explained the flag).
I have the same situation on my system. Make sure the Windows OS Archive Flag is not set on the local system for the files. SQL Backup will not delete these files if the Archive Flag is set (even if the file meets the date time criteria).
Mike / comments
MasterCephus wrote:
ok Setting FILEOPTIONS = 3 didn't work...in fact it didn't delete on local disk and on the network...
By reading what the FILEOPTIONS flag does, I have to think this has to b...
MasterCephus wrote:
are you talking about removing the read-only flag from the backup folder?
No. One of the File Attributes Windows puts on a File is "Archived" (A). Read-Only (R), Hidden (H), System (S) are some other File Attributes.
The Archived Flag is designed to be used by backup systems so when a file is created it gets the Archive Flag. When certain Windows backup software backs up the file, it removes the Archive Flag. This is Windows way of protecting files that have not been backed up (to tape or whatever) from being deleted prematurely.
SQL Backup product looks for that flag and if it is set, it will not delete the local .sqb files.
In Windows Explorer, right-click on the File and choose properties. Then click on the "Advanced" button in the Attributes section of the form. The "File is ready for archiving" will be checked if the Archive Flag is true.
Mike / comments
MasterCephus wrote:
are you talking about removing the read-only flag from the backup folder?
No. One of the File Attributes Windows puts on a File is "Archived" (A). Read-Only (R), Hidden (...
Peter,
It turns out it was the FILEOPTIONS setting that was causing the problem. The files in question did have the Archive flag set. By setting the FILEOPTIONS = 5, then the old backup files are deleting correctly. When reading through the help file for the BACKUP command Settings, it was not clear that ERASEFILES could be used without FILEOPTIONS = 2 (or any mask value containing option 2).
Thanks for all your help.
Mike / comments
Peter,
It turns out it was the FILEOPTIONS setting that was causing the problem. The files in question did have the Archive flag set. By setting the FILEOPTIONS = 5, then the old backup files are...
Peter,
I added the debug flag to the service and I can see the entry for "DeleteOldFiles.Collecting [image] :\DatabaseBakups\ - 0 entries" as well as one for the CopyTo folder location.
Is there a way to tell why a specific file is not deleted when it meets the criteria of the ERASEFILES and FILEOPTIONS options?
I have setup the same process on a Test Server (without the SERVERNAME issues) and I am still seeing the same problems. The old files are not deleted.
Mike / comments
Peter,
I added the debug flag to the service and I can see the entry for "DeleteOldFiles.Collecting :\DatabaseBakups\ - 0 entries" as well as one for the CopyTo folder location.
Is there a way to t...
Peter,
Should the File Deletion (or the attempt to do so) be in the Log file?
The log file displays that the process completed successfully, gives all the details about the backup, then shows the Verifying Files step, then the Copying step. Then the "SQL Backup Process Ended" message. Should there be a message about trying to Delete old files in the Backup folder, as well as trying to delete old files in the CopyTo folder?
How do I tell if it is even trying to Delete the old files?
Mike / comments
Peter,
Should the File Deletion (or the attempt to do so) be in the Log file?
The log file displays that the process completed successfully, gives all the details about the backup, then shows the V...
Peter,
The value stored on the new backup files is the original server name -- which is what I guessed was there from looking at the RedGate SQL Backup logs.
For the current database that is being backed up, what is the method used to determine the "details of the database being backed up" with regards to the name of the SQL Server?
Mike / comments
Peter,
The value stored on the new backup files is the original server name -- which is what I guessed was there from looking at the RedGate SQL Backup logs.
For the current database that is being ...
eddie davis wrote:
Can you please confirm to me, if you are backing up multiple databases in a single job to a network share?
In my testing for the fault condition, I can only recreate the problem when the backup job is to a network share.
Eddie,
I was backing up a single database to a single file on a local drive. It happened two nights in a row. When I open the GUI now (a week later) the backups statuses say they are complete. I have not seen this issue on a second server that we have running with SQL Backup 5.3.
Mike / comments
eddie davis wrote:
Can you please confirm to me, if you are backing up multiple databases in a single job to a network share?
In my testing for the fault condition, I can only recreate the pro...
I am using SQL backup version 5.3.0.178 and am still experiencing this problem. I have a job that backs up a number of databases and the largest one (60 GB) says it is still "In Progress" and "Finishing" the backup even though it completed about 11 hours ago. When double-clicking on the backup record in the GUI, it states that the backup completed without any errors or warnings.
So it looks like this issue is not entirely fixed in version 5.3.
Mike / comments
I am using SQL backup version 5.3.0.178 and am still experiencing this problem. I have a job that backs up a number of databases and the largest one (60 GB) says it is still "In Progress" and "Fin...