So… Due to all these things I just gave up… I wiped my Backblaze container, deleted the duplicacy folder on the repository and started from scratch.
And then I found 2 other issues and to both I propose solutions: (I do this with the best intentions, not criticizing, I know enough programming to know that it is hard work, respect )
Even though it was the 1st backup, the logs kept checking whether or not the chunk already existed before uploading it,
2018-12-01 23:35:42.858 DEBUG BACKBLAZE_CALL URL request ‘HEAD https://f002.backblazeb2.com/file/ContainerName/chunks/ChunkName’ returned status code 404
2018-12-01 23:35:42.858 DEBUG BACKBLAZE_LIST b2_download_file_by_name did not return headers
2018-12-01 23:35:45.937 DEBUG CHUNK_UPLOAD Chunk ChunkName has been uploaded
2018-12-01 23:35:45.937 INFO UPLOAD_PROGRESS Uploaded chunk ChunkNumber size 5968306, 3.03MB/s 6 days 07:44:32 34.2%
Which I guess it’s fine… But it definitely looked like was wasting precious time…
Maybe add an option that either: Wipes the container before beginning (Maybe add a warning like "I know what I’m doing, wipe before beginning, this is the initial backup) or just asks: Is this an initial backup? Is the container free of any chunks or conflicting files? Do you know what you’re doing?..
After more than a week, (On a 50/50 mbps link) the backup finally finished.
However, I’m still getting no email notifications even though the logs say the email was sent correctly…
04:51:41.000 CURL: 235 Authentication Successful
04:51:41.000 CURL: MAIL FROM:<source@email>
04:51:41.000 CURL: 250 Sender <source@email> OK
04:51:41.000 CURL: RCPT TO:<destination@1>
04:51:41.000 CURL: 250 Recipient <destination@1> OK
04:51:41.000 CURL: RCPT TO:<destination@2>
04:51:42.000 CURL: 250 Recipient <destination@2> OK
04:51:42.000 CURL: DATA
04:51:42.000 CURL: 354 Ok Send data ending with .
04:51:42.000 CURL: From: source@email To: destination@1;destination@2; Subject: Deduping Status Log file: \Repository\.duplicacy\logs\backup-log-20181204-163300 2018-12-04 16:33:00.929 INFO STORAGE_SET Storage set to b2://ContainerName 2018-12-04 16:33:00.932 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_GUI1_B2_ID 2018-12-04 16:33:00.948 DEBUG PASSWORD_KEYCHAIN Reading b2_id from keychain/keyring 2018-12-04 16:33:00.948 DEBUG PASSWORD_ENV_VAR Read
My theory is that it is trying to attach the log file, the log file exceeds the 25 MB attachment limit of my email service and never gets sent, I totally can understand such limitation, however, I really need email notifications.
If my theory is correct, I already have a 3 solutions: (I like all of them… Maybe all of them are possible )
- Create an option that: if attachment file is bigger than (Email’s attachment limit), split the log into chunks (Maybe a ZIP) and sent it that way, you would end up with some messages, like:
“Duplicacy backup successful (1/3)”
“Duplicacy backup successful (2/3)”
“Duplicacy backup successful (3/3)”
- Create an option that: if attachment file is bigger than (Email’s attachment limit), skip log file attachment, messages would be like:
“Duplicacy backup successful (Log file size exceeds server limit, check source for details)”
- (The logical evolution of #2) Create an option that: if attachment file is bigger than (Email’s attachment limit), upload log to a google drive (Or dropbox or whatever) folder:
“Duplicacy backup successful (Log file size exceeds server limit, uploaded to specified cloud folder)”
Is my theory correct? or am I doing something wrong, in any case, how can I resolve it?