Error: The attachability check has failed, No log files were found for this database

For the message "No log files were found for this database" the first thing I recommend is to make sure the volume where the database log file resides is protected and within the same protection group as to where the rest of the database files are. 

In order to do that click the agent, you are having problems with, and then go to the summary page, if the volume where the logs is in a different protection group or has not been protected it will look something like this: 

if that is the case, you need to checkmark all the volumes that have database files and then click "set a schedule" and set the protection schedule you want for them and save. From that point forward every time it takes a backup all the volumes will be in the same protection group and you should not see any warning or error message anymore. 

It will look more like this, just a single row for all the volumes

Hello Victor,

Thanks for your reply.

In my unterstanding this is already set as you describe it, unfortunately i can't paste my screenshot in here but it looks like your second image. And a schedule is set for the whole group as well.

Do you have another hint, which could generate this error? In case this database wouldn't exist anymore on the server, the error message would be another one right?

Best regards

Simon

If it is already set in the same protection group, the next step would be to confirm the log file is in fact being backup. In order to do so you need to check the log file location for the databases X1, X2, X3, and X4 and then mount the recovery point of the volume where they are supposed to be and confirm if the log files are there or not. 

Another thing to try is to try to attach the database manually by mounting the recovery point and from the SQL Management Studio attach it.

Hi Victor,

I created a recovery point and the log files of the databases are getting backed up. I copied some of the databases then to my local computer and tried to attach them in  SQL Management Studio and that worked as well (after some work to get the correct user rights etc.)

I'm not sure if this is relevant but I have some "yellow dots" under "SQL Server Information":

https://www.dropbox.com/s/5n501hsypfg59xo/sql_server_yellow_dots.png?dl=0

I feel like an idiot but I am not able to insert images in this post, that's why I uploaded the image on dropbox for you. Hope this helps..

Best regards

Simon

I see,

if you hover your mouse cursor over the yellow dot it should tell you why it is in yellow. 

Regarding the screenshot, you can either use the insert button/image/video file or simply copy and paste the image, that is what works best for me, copy/paste I mean. 

Yes it tells me "no access to database". I already checked the server in the current state and this paths don't exist (anymore). Could that cause the error?

Unfortunately copy and paste does not work for me. And with Insert Image, it asks me for an URL if I paste the local path of the pictures it says, "this URL is no allowed to be inserted"

Best regards

Simon

If the path does not exist anymore, it could be the metadata is not updating for the agent in the core and is still pointing to that database because of that. The best way to fix the metadata problem is to remove the machine from protection (keeping the recovery points) and re-adding it.

If this is agentless protection you don't need to do anything else, however, if the server is protected via agent instead, removing and re adding the server from protection might trigger a base image, if this is a 6.5+ core and agent you can enable synthetic backup in the core settings to avoid the base image from triggering. 

Hello Victor

I removed the machine and re-added it. Still the same "problem". Very strange..

is there something else i can check to get rid of this "yellow dots" or "attachability errors"?

Best regards

Simon

There must be something that we are missing, At this point is difficult to tell without a session so I recommend you to create a support ticket so one engineer can do a proper support session and pinpoint the culprit of the problem. 

Sorry I was not able to help you on this one.

Just throwing in some food for thought, I'm not an expert on the SQL attachability check - I honestly never really turned it on. I never turned it on however as SQL Express is not supported: https://support.quest.com/technical-documents/rapid-recovery/6.1.3/user-guide/35

These errors might not correlate, however I can't help but wonder if there is a missing config file, .dll, something, as the product has always said 'licensed' SQL for both the protected machine, and the one doing the check. 

I know it isn't a popular opinion, however that very well could be why you're getting warnings. I'll admit, I'm reading your errors that says Express right in it, so I 'assume' at this point it is free SQL. Which may or may not work, however if the documentation says licensed on it, it's probably not intended to work. 

Not a popular popular opinion, sorry Simon. It is an honest one though. Cheers, good luck.