• State Suggested Answer
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 4386 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Error: Nightly attachability has finished with error(s)

Chafmt
over 6 years ago

Looking for some guidance into this error we're getting. Google is letting me down on this one, in case somebody knows where to start looking on this:

---

One or more SQL Server databases failed the nightly attachability check

Failed due to multiple errors


* Missing Method Exception: Method not found for this Request.

* Instance Attachability Check Failed Exception: Failed to check the attachability on the SQL Server instance GP. Reason: Call to service method https://xxx:8006/apprecovery/api/agent/sqlserver/attachabilityCheckStatus/ GET failed: Method not found for this Request.

* Attachability Check Failed Exception: Call to service method https://xxx:8006/apprecovery/api/agent/sqlserver/attachabilityCheckStatus/ GET failed: Method not found for this Request.

* Instance Attachability Check Failed Exception: Failed to check the attachability on the SQL Server instance TF. Reason: Call to service method https://xxx:8006/apprecovery/api/agent/sqlserver/attachabilityCheckStatus/ GET failed: Method not found for this Request.

  • 0 over 6 years ago

    Hi Chafmt:
    In order to perform attachability you need a full version of a SQL server engine. AppAssure needed the SQL engine to be installed on the core while Rapid Recovery offers the option to perform the attachability test straight on the originating SQL server (make sure that it does not overload production servers).
    The attachability process involves mounting the recovery point containing the SQL databases. Therefore, the account used to connect to the database engine performing the job needs to have access to the folders containing the databases on the recovery point (as in NTFS permissions).
    At last but not at least, the storage subsystem on the core does not need to be overwhelmed by other requests so the recovery point to check can be mounted in time and the database access is sufficiently quick for the job to run without timing out.
    In your case, all the error messages point toward a get method which is meant to find out if the attachability job can be executed on the SQL server in question
    (the job seems to be requested on the agent). Could it be possible that the agent is offline, that the SQL service is not running or the WMI subsystem is not performing properly?
    Check this KB: support.quest.com/.../122778 for some possible solutions (the mofcomp lines may be the best fit for a fix).
    Hope that this helps.