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?
Internet Options:
Compressed Transfer, Calculate file-hashes on the client, connect to internet server if connected to local
Even after a few hours it was still showing shows 5 days 1TB left?
Sometime is see transfert speed not possible (like 500kb/s on a 100kb line) and i guess that’s the hashing kicking in.
So i guess the time left counter should go down very fast after a few hours if seeding is actually working.
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.
Pre-seed was done from Windows 10 with 2.2.9-cbt client. Just re-ran the seed, and it took 1 minute, no rehashing of files.
We have a few other computers remotely backing up, but they were not seeded. When I run incremental backups, they also are fast and don’t require re-reading data.
Tonight we will shutdown the server and upgrade to 2.2.9-cbt beta and see if that fixes it.
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==)