Make sure you are facing Replication Issue: Run a backup from the source location to destination location. If that fails then your problem is not Replication issue but a more general problem that requires further troubleshooting and localization.
Follow these steps to troubleshoot Replication Issues:
- Get familiar with technology of Replication in the About part.
- Follow to Troubleshooting part to troubleshoot and resolve the issue.
Things you need to know about replication
- Replication is not a copy. Replication is more similar to rebackup. As the source of the rebackup the original backup is used. This is the current design and is done to make replication process universal for all locations. So you should not expect from replication performance of “Copy/Paste”
- Replication is replicating archive, not backup. Replication of archive “MyArchive” from destination “A” to destination “B” will replicate ALL backups in “MyArchive” from location “A” that are not yet present in “MyArchive” in location “B”. So if you are doing Daily incremental backups and weekly full, you cannot copy only Weekly full backups using replication. In this case incremental backups will be replicated too. See: Web Help: Setting up replication of backups
- Replication is performed from location #N to location #N+1. That means that the backup is replicated from location one to location two, then from location two to location three etc.
- When backing up to unmanaged vault Replication is performed by agent. So if you are backing up to a network share “A” and replicating backup to network share “B” the Agent that performs backup will replicate it. This will basically double the network transfer as the data will go from “A” to agent and then from agent to “B”.
- When the source location of replication is Managed vault then the storage node performs replication. However Agent that was doing the backup initiates this process and monitors it.
- Replication is part of a Replication/Cleanup task. If replication part of the task fails then cleanup on this location does not start since it is dangerous to clean the data when it was not transferred to another location yet. Same is true for a failure in the cleanup part of the task. If Cleanup fails, the whole task fails.
- Replication from deduplication vault will undeduplicate the backup first then send undeduplicated data to destination and deduplicate it there. In this case 1st Storage Node acts like agent. So if deduplication on source is enabled then it will be handled by 1st Storage Node.
Follow step-by-step instructions below to troubleshoot the issue. Complete error troubleshooting step.
Possible reasons of replication failure:
- You are replicating a corrupted backup.
- Archive metadata inconsistency.
1. Error troubleshooting
Complete all steps before proceeding to collect information step.
1.1 If replication/staging fails with:
The requested hashes have not been found in the deduplication database.
(Relevant only when replicating from a Managed vault with Deduplication enabled)
Error occurred while backing up.
Error code: 3Module: 4LineInfo: ce542e14da2039b6Fields: Path : Drive:/Folder1/Folder2/File.JPG
Then you are having a problem with your backup at source location. Please validate the archive and if it fails refer to Troubleshooting Issues with Corrupt Backups
1.2 If replication/staging fails with:
Failed to open the backup archive by the ID
Failed to open the archive for reading
Then you are facing metadata inconsistency problem. The cause of metadata inconsistency can be very different.
For example: After every operation Backup/Replication/Cleanup Acronis updates the metadata of the archive. If for some reason updating of metadata fails it creates metadata inconsistency. Such as if updating metadata on cleanup fails then the metadata will still hold the backup that was already removed. And next replication task will try to replicate and will fail trying to find it. The cause of the above however usually lies in the problems with hardware on the backup location. For example if the backup location does not have enough space the metadata update can fail. Or if the target location file system is damaged the meta update can fail. Look for errors in the logs such as “Failed to rename file”. They should provide a clue on the time when metadata got inconsistent.
To fix the metadata problem you have to click the Refresh button in the vault view a couple of times, it should force the metadata update.
1.3 If replication/staging process hangs, please proceed as described in this article.
If all steps above have been executed and the issue still persists, go to collect information step.
2. Collect information
Collect following information and contact Acronis Support.
2.1 Step-by-step description of the issue
Provide a step-by-step description with screenshots illustating the faulty behaviour.
2.2 System Report
System Report from the source of replication. System Report from the agent that performed backup. System Report from the destination of replication. See instruction for Acronis Backup 11.7/11.5 Generating System Report, if this fails for any reason, you can use this AcronisInfo Utility
2.3 Process Monitor log
Reproduce the problem and collect Process Monitor log during replication failure.
2.4 Target location logs (if the location is a NAS)
Device specific logs.
E.g.: if the target device is a NAS that means that it has its own OS (usually linux) and that it has its own logs. If there is ability to export those logs from the NAS web console please provide those logs. If the device does not have that ability but it has SSH access then you should use Putty and WinSCP to connect to that NAS via SSH. Login and password are usually the same as the login and password to NAS web console. Then look for the following file and download then via WinSCP: /var/log/messages Also we will need the server side logs of the sharing application. If that is a linux based NAS then its sharing is usually based on application called SAMBA. That means that you need to search for samba.log or cifs.log. The file name can be different such as samba-DATE-TIME.log and so on. So when connected with Putty issue the following command to look for the log: find / -name samba find / -name cifs and see what files are outputted and if there is a log there. Then download it via WinSCP.