We have setup local and off-site backups, however, the pre-seeding of backups isn’t always working. To pre-seed, we copied all files to an external drive, attached to client local to the remote server, performed backup. In that client’s backup, all files can be found and restored as needed.
Initial test was with 500GB of data, pre-seeding worked perfect, only took an hour or so. Seeded additional 1TB of data, started incremental file backup and now shows 1TB of data to backup and 5 days.
When original client connects, it appears to be be loading most of the files and hashing them on the server, not hashing on the client. Log on the server is showing:
DEBUG No old file for “file1” (2)
DEBUG GT: Loaded file “file1”
DEBUG: PT: Hashing “file1”
DEBUG: HT: Linked file: “file1”
Often loading file shows “x% finished xxx MB/yyy MB at xx MBits/s”
Is there a way to confirm client side hashing is done? Or another way to force it?
Compressed Transfer, Calculate file-hashes on the client, connect to internet server if connected to local
Pretty out there theory: There was actually a bug in the sha hashing function in older servers/clients fixed with 2.2.x. If your server is upgraded from >=2.0.x this might cause the hash mismatches. So try it with a 2.2.x client.
Edit: Actually, this should cause errors. So this is probably not the reason.
About an hour and a half after the backup started, there was an error. Then 5 hours after starting,the backup finished, however it failed.
In the logs is:
Client calculated hash of “file1” differs from server calculated hash. This may be caused by a bug or by random bit flips on the client or server hard disk. Failing backup. (Hash: tree-sparse, client hash: 34NBPa5rAFOKmBhI7I3Mw3AenNgBAABgAQAAYAAB/2ABAABQAQAAUAEAAFABAABQAQAAUAEAAFABAABQAQAAUA==, server hash: GcNkDqTdRehx+LiKzfdxfzseTiIBAABgAQAAYAAB/2ABAABQAQAAUAEAAFABAABQAQAAUAEAAFABAABQAQAAUA==)
FATAL: Backup failed because of disk problems (see previous messages)
Turning on the option to ignore hash mismatch allowed the backup to complete.
Prior to that, the backup failed on the same file twice:
Client calculated hash of “/data/backup/server/180403-1358/d/System Volume Information/SRM/quota.md” differs from server calculated hash. This may be caused by a bug or by random bit flips on the client or server hard disk. Failing backup. (Hash: tree-sparse, client hash: 34NBPa5rAFOKmBhI7I3Mw3AenNgBAABgAQAAYAAB/2ABAABQAQAAUAEAAFABAABQAQAAUAEAAFABAABQAQAAUA==, server hash: 37OeRmBLCZKUlOiMOXYAGAEe744BAABgAQAAYAAB/2ABAABQAQAAUAEAAFABAABQAQAAUAEAAFABAABQAQAAUA==)