Considering that you have the latest TKLBAM, everything looks ok in your Hub account, ping is responding as expected, and that I can't reproduce this issue in a local VM from my end (here in Australia), it is almost certainly something within your VM and/or your environment (e.g. host system if running as a VM; networking within your LAN and/or infrastructure including internet connection). To break it down a bit further, my guess is one of:
Some non-obvious change to do with the new ISP plan. Whilst rare, there is precedent for this and we've seen it before; the ISP denied any changes, but changing ISP completely resolved the issue. This seems somewhat unlikely given your notes, but can't be completely ruled out considering that fact that ISP changes coincided with this issue occurring.
Some local issue such as corruption of some sort, or lack of free disk space (if a VM, perhaps on the host?) - which is for some reason giving an error message that isn't related to the real cause.
So unless connecting to the internet via an alternate path is an easy option and/or you want to contact your ISP and explicitly ask them about any changes/difference that may affect encrypted traffic, let's put the ISP possibility aside. (Also FWIW even if you do contact your ISP they may deny any changes regardless).
So to focus on potential issues related to your local TurnKey appliance, assuming that it's a VM, please double check the host system has plenty of free space. If your VM has a dynamically assigned disk, if the host runs out of free space (or is very close), then the guest may act as if it has also run out of space despite showing that it still has free space. I'd also suggest checking system logs on the host to
Assuming that's ok, within your TurnKey appliance, check the available disk space like this:
df -h
Look for the line that is "Mounted on" "/" (it should either be '/dev/mapper/turnkey-root" or "/dev/sda1"). Then double check how much is "Avail" (available). E.g. here's the output of a VM I have handy:
Mine has a root filesystem of 12GB, with 3.5GB used and 7.5GB free. If yours has less than a few hundred MB free that is quite likely the cause. If you're unsure, please feel fre to post your output.
If everything is still looking ok for now, you could try manually clearing the caches. I'm not sure that this will help, but perhaps? Do that like this:
If you still get the same issue, then the next thing to check is to re-initialise your server. This will test to see if your current credentials and config are corrupted. We'll keep the current data just in case that doesn't resolve this issue. In an ideal situation, you would have enabled as least "Backup Standard" (@$10/month) so that you can test creation of a new backup (I note that you're currently on "Backup Free). But I'm pretty sure that this process should be able to test re-initialisation without upgrading to a paid plan (even though you won't be able to fully test creation of and uploading) a backup. SO here's what you'll need to do:
That should allow you to re-initialise your server as if it was a new server. It should succeed. If it does, you can then move on to test creation of a backup (this step will fail if you don't upgrade to a paid backup plan; but the error should be different to your previous error - it should explicitly note that it can't upload). So again try this:
tklbam-backup
If you get the same error as before and/or the tklbam-init step above gives a similar error message then it seems most likely to me that it must be an issue with your environment (e.g. LAN and/or internet connection). I guess you could test creating a new VM and checking to see if that can connect and if it generates the same errors or not, but I'm not sure how much that will help you diagnose. It would probably require capturing network traffic and comparing to traffic from a working system.
Ok, so you have the latest TKLBAM release for v15.x.
Considering that you have the latest TKLBAM, everything looks ok in your Hub account, ping is responding as expected, and that I can't reproduce this issue in a local VM from my end (here in Australia), it is almost certainly something within your VM and/or your environment (e.g. host system if running as a VM; networking within your LAN and/or infrastructure including internet connection). To break it down a bit further, my guess is one of:
So unless connecting to the internet via an alternate path is an easy option and/or you want to contact your ISP and explicitly ask them about any changes/difference that may affect encrypted traffic, let's put the ISP possibility aside. (Also FWIW even if you do contact your ISP they may deny any changes regardless).
So to focus on potential issues related to your local TurnKey appliance, assuming that it's a VM, please double check the host system has plenty of free space. If your VM has a dynamically assigned disk, if the host runs out of free space (or is very close), then the guest may act as if it has also run out of space despite showing that it still has free space. I'd also suggest checking system logs on the host to
Assuming that's ok, within your TurnKey appliance, check the available disk space like this:
Look for the line that is "Mounted on" "/" (it should either be '/dev/mapper/turnkey-root" or "/dev/sda1"). Then double check how much is "Avail" (available). E.g. here's the output of a VM I have handy:
Mine has a root filesystem of 12GB, with 3.5GB used and 7.5GB free. If yours has less than a few hundred MB free that is quite likely the cause. If you're unsure, please feel fre to post your output.
If everything is still looking ok for now, you could try manually clearing the caches. I'm not sure that this will help, but perhaps? Do that like this:
Then retry running 'tklbam-backup'.
If you still get the same issue, then the next thing to check is to re-initialise your server. This will test to see if your current credentials and config are corrupted. We'll keep the current data just in case that doesn't resolve this issue. In an ideal situation, you would have enabled as least "Backup Standard" (@$10/month) so that you can test creation of a new backup (I note that you're currently on "Backup Free). But I'm pretty sure that this process should be able to test re-initialisation without upgrading to a paid plan (even though you won't be able to fully test creation of and uploading) a backup. SO here's what you'll need to do:
That should allow you to re-initialise your server as if it was a new server. It should succeed. If it does, you can then move on to test creation of a backup (this step will fail if you don't upgrade to a paid backup plan; but the error should be different to your previous error - it should explicitly note that it can't upload). So again try this:
If you get the same error as before and/or the tklbam-init step above gives a similar error message then it seems most likely to me that it must be an issue with your environment (e.g. LAN and/or internet connection). I guess you could test creating a new VM and checking to see if that can connect and if it generates the same errors or not, but I'm not sure how much that will help you diagnose. It would probably require capturing network traffic and comparing to traffic from a working system.