This article provides advanced troubleshooting steps for the Datto Windows Agent.
- Datto Windows Agent
- The ShadowProtect Diagnostic tool is a StorageCraft-only utility, and does not work with the Datto Windows Agent.
- The Datto Windows Agent's primary backup transport method for Versions 2.0 and up is called MercuryFTP. Agents below Version 2.0 will back up using iSCSI. The Datto Windows Agent will also fall back to iSCSI if MercuryFTP transport is unavailable.
- For the Datto Windows Agent to communicate successfully, port 3262 (MercuryFTP) and 3260 (iSCSI) must be open and accessible from the production machine to the Datto device.
- See this article for information about accessing and exporting backup logs for the Datto Windows Agent.
Similarities to the ShadowSnap Agent
- The Repair Agent Communications button found under Protect → Configure Agent Settings in the Daevice Web UI works with both the ShadowSnap agent and the Datto Windows agent.
- The logs found in /datto/config/keys/(agent).log provide the same backup level information for the Datto Windows Agent that they do for the ShadowSnap agent.
Microsoft Exchange Log Truncation
- When using the Datto Windows Agent, Exchange will interpret backups as full VSS backups (VSS_BT_FULL). If the VSS framework and the Exchange Writer are functioning properly, Exchange log truncation will occur. The incremental tracker will then dictate which blocks to back up.
Accessing the Agent Logs
The Datto Windows Agent activity logs most of its activity to the agent.sqlite file. You can find this file in one of the following locations:
Windows Vista and up
systemprofile\AppData\Local\ Datto\Datto Windows Agent\agent.sqlite
Windows XP / Server 2003
- C:\Documents and Settings\NetworkService\Local Settings\Application Data\Datto\Datto Windows Agent\agent.sqlite
When you work with the agent.sqlite file, make a copy of it, and work with the copy, so that you do not interfere with any active jobs. If you run into errors when attempting to parse the file in the location mentioned above, copy the file to a Windows directory where the user has full permission to interact with the file.
You can parse the using an SQL database viewer, such as DB Browser for SQLite (external link), by following these steps:
1. Open the .sqlite file
2. Choose the Browse Data tab
3. Switch the Table drop-down to Logs, and then expand the Message field. You will see granular information about all backup processes since the initial backup, sorted by date and time.
You can also run the following curl command from the Datto appliance's command line against any machine running the Datto Windows Agent to audit log information:
snapctl agent:request <agentuuid> event
snapctl agent:request 2b5ba66efdb1448c8b45aabf1343b9d0 event
Backup Codes and their Meanings
When browsing backup logs, any indication of a critical failure will have an associated message as well as indicate a Snapshot state. This will give you an idea of how the backup failed and where in the process the failure occurred.
- States 1 and 2 are the Windows/VSS creation process.
- State 3 is maintenance of the image file while we move it block by block over to the Datto dataset.
- State 4 is the tracking process between backups where the agent identifies updated blocks that will need to be transferred during the next backup.
Knowing where the process failed can help you decide where to begin troubleshooting. If the process failed during Steps 1 or 2, you can start by investigating VSS on the target server. If the failure occurred during Step 3, you should begin by checking connectivity/network variables.
Snapshot states or phases for a specific volume:
0 = Not Configured. A snapshot does not exist for the volume.
1 = Snapshot is in the first preparation phase.
2 = Snapshot is in the second preparation phase.
3 = Snapshot is in the frozen, read-only phase. This is the phase a snapshot should be in for backing up.
4 = Snapshot is tracking changes. This is the period between backups so an actual, readable snapshot does not yet exist.
5 = Snapshot is in an error state (see below) and will have to be reset. This should be accompanied by some error code.
If an error occurs during a snapshot phase, the snapshot may be in the following error states:
1 = First preparation phase error state
2 = Second preparation phase error state
3 = Frozen, read-only phase error state
4 = Change tracking phase error state
5 = Shutdown phase error state
6 = Volume resize error state
Windows Error Codes
The Datto Windows agent also uses standard Windows system error codes in its logging. If you are reviewing an error in the agent logs, such as
Error while retrieving
used block bitmap. [-33], you can determine the meaning of the error code in brackets (in this case, 33), by consulting MSDN: System Error Codes (external link).
Windows Event Viewer
- If the Windows Event Viewer logs any events involving the agent, it records them with DattoBackupAgentService as the source in the Application logs.
- A failing writer can cause a snapshot to fail, in turn causing a backup to fail. To diagnose failing writers, you can look for VSS errors in the Application logs. Look for events involving the agent's driver files, DattoFltr.sys and DattoBusDriver.sys.
- You can also use the vssadmin application through the Windows Command Prompt. The vssadmin list writers command will display writer failures.
Checking the MercuryFTP Transport Service on Ubuntu 16.04
Backup failures can also occur if the MercuryFTP transport service is not running.
You can verify that MercuryFTP is running by using the
ps -lfx | grep -i mercuryftp | grep -v grep command from your Datto appliance's command line. If the service is not running, use the
systemctl start mercuryftp command to start it.
Once MercuryFTP is running, make sure that it is listening on port 3262 by using the
netstat -pln | grep merc command.