Track down what triggered a SQL backup attempt
In the SQL Server logs there was an error event when it attempted to backup a transaction log to a file to a non existent path. The thing is, we don't know what triggered the backup attempt. Poured over the maintenance logs and SQL Agent Jobs and cannot find anything. Is there a way to track down what triggered this backup request? If not for this one, then something to set up in case it happens again? Everyone who has access to the server insists they didn't do it. It is possible that it is a stored procedure or something that is programmed to backup the log to a file when triggered (maybe for troubleshooting) but I don't know how to track that sort of thing down. The path it attempted to use is very unique so if there is a way I could do some sort of comprehensive search that would work.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Check in the SQL Server Error log or in the Windows Event Log as the Backups are logged.
ASKER
Thanks all. Using the query from Darran we were able to reverse engineer the fact that someone was programmatically triggering a log backup trying to gather info when a certain condition was met. I am no SQL guru but this seems like a bad way to go about troubleshooting an occurrence in a DB since wont this mess up the normal restore sequence if we needed to roll back? Seems like you would want to trap to maybe another DB or something.
Possibility: Somebody has enough access to the system to trigger the backup and wants to steal info.
Check to see who was logged in when the attempt occurred.
Do a full virus sweep on the system using at least two different antiviruses, then run Malwarebytes, then run Spybot - S&D.
Do a file content search and look for the file pathname inside all files, including system files and archives. Search for the full pathname and for likely substrings.
If your web server is located on the same system, move it to different hardware (even if it is virtualized). This is good general procedure and will eliminate somebody getting into the system through a server exploit.