Repository navigation
Replies: 6 comments
|
Thanks for the ideas... Much appreciated. Read through it, and am considering ideas. Unsure if it's relative, but my borg server in this case is running in a docker container on a Fedora server. Decided to try and remove variables from the equation, so quickly built a new Fedora VM, and installed borg on it natively from the Fedora repos. Did a quick full backup and restore/extract (with no encryption). The same 6GB home directory from the same client. Works fine repeatedly. Going to add encryption back into the repo next to see if it still works. If so, I guess I'll abandon the docker idea. It wasn't that important to me, I'll just run the borg server natively in a VM instead. |
|
Just to reduce the amount of variables in your investigation: The problem is on a level below the ssh protocol - data packets get corrupted somewhere (e.g. bit flips) and ssh notices it because it is using strong cryptographic checksums (MACs, message authentication codes). So it's quite unrelated to borg (except that borg is causing maybe more traffic than your other applications) and also unrelated to ssh. But somewhere below these: network software, drivers, hardware (including RAM). |
|
I was mildly suspicious of something like that.... really neat extra info,
thanks for that !
In troubleshooting:
- Had success by installing a brand-new Fedora 36 host, installing borg,
and doing backup/restore
- So moved back to my troublesome borg server (within it's docker container)
- I've eliminated the container (by moving everything up to the overlying
host). Still seeing failures.
- Should have mentioned, my repos are sitting on a mounted filesystem,
coming from a Synology via SMB protocol.
- So moving those repos over to a local FS to see if that makes a
difference.....
…On Tue, Nov 22, 2022 at 12:01 PM TW ***@***.***> wrote:
Just to reduce the amount of variables in your investigation:
The problem is on a level below the ssh protocol - data packets get
corrupted somewhere (e.g. bit flips) and ssh notices it because it is using
strong cryptographic checksums (MACs, message authentication codes).
So it's quite unrelated to borg (except that borg is causing maybe more
traffic than your other applications) and also unrelated to ssh. But
somewhere below these: network software, drivers, hardware.
—
Reply to this email directly, view it on GitHub
<#7152 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACHI2ZAL5RSJ3F57FIOSZ2TWJT37FANCNFSM6AAAAAASHDIAAA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hmmmm, first test done with 6GB extract using borg (server) repo sitting on local disk (rather than mounted CIFS/SMB filesystem). Works. Testing again to be sure. So, is there something inherently bad about using a repo that's mounted using CIFS v3 (from a Synology) ? I'm using this config because most of my (redundant) storage is sitting on a Synology. I don't want to install the BorgBackup server on the synology directly, would rather use a separate VM for that. |
|
Closing this as outdated: it has seen no activity for a long time and predates the current borg releases. If this still affects you on a current version - borg 1.4.x (stable) or the borg 2.0.0 beta - please open a new discussion with up-to-date details. |
Uh oh!
There was an error while loading. Please reload this page.
Relatively new user to borgbackup.
I'm seeing consistent failures when performing a "borg extract" from a ssh repo when using Wi-Fi between client and server
I'm seeing intermittent success if I attempt same "borg extract" from from a ssh repo when using wired ethernet between client and server
Network setup (in my house) has been very reliable otherwise, very pleased with it. For reference, it's entirely a Ubiquiti setup.
Here's the error I'm getting:
Remote: ssh_dispatch_run_fatal: Connection to 192.168.1.63 port 2201: message authentication code incorrectAny ideas on where I can start to trouble-shoot this ?
All reactions