Re: Tarsnap connection lost, not sure how to debug
Realised I did not answer your questions -- I am running this from a cloud server on DigitalOcean's network. A similar server on DO's network functions without issue. Networking-wise there are two adapters, eth0 and eth1, which connects to the internal network. This might've been added after tarsnap was set up... Perhaps that could be significant? # ls -l .tarsnap-cache total 0 -rw-r--r-- 1 root root 0 Feb 21 12:26 lockf # ls -ld .tarsnap-cache drwx-- 2 root root 4096 Feb 21 12:26 .tarsnap-cache On Fri, Apr 5, 2019 at 3:41 PM Julian Lam wrote: > Hi Graham/Colin -- I did see that page before and ran through the items. > No problems pinging or connecting via telnet, and a different server > configured the same way (at roughly the same time, give or take a couple > days) connects just fine. Thought maybe ufw was getting in the way, so I > punched a hole for requests to tarsnap's IP (no effect), and disabled it > outright (also no effect). > > I'm seeing no obvious permission errors (I'm actually running as root), > and I had also tried defining a new cache directory, which also didn't make > any difference. > > On Fri, Apr 5, 2019 at 2:35 PM Colin Percival > wrote: > >> In addition to Graham's comments about debugging the network... >> >> On 4/4/19 7:20 PM, Julian Lam wrote: >> > Seems I'm running out of money on my account, so I wanted to go ahead >> and nuke >> > what I had, except I'm unable to at this time: >> > >> > /usr/bin/tarsnap --key tarsnap.key --cachedir .tarsnap-cache --fsck >> >> If you want to nuke *all* of your archives, you don't need to run --fsck. >> You only need to have a synchronized cache directory for creating new >> archives or deleting *individual* archives (since that's how tarsnap >> figures out which blocks are no longer needed -- not an issue if you ask >> to delete everything). >> >> -- >> Colin Percival >> Security Officer Emeritus, FreeBSD | The power to serve >> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly >> paranoid >> >
Re: Tarsnap connection lost, not sure how to debug
Hi Graham/Colin -- I did see that page before and ran through the items. No problems pinging or connecting via telnet, and a different server configured the same way (at roughly the same time, give or take a couple days) connects just fine. Thought maybe ufw was getting in the way, so I punched a hole for requests to tarsnap's IP (no effect), and disabled it outright (also no effect). I'm seeing no obvious permission errors (I'm actually running as root), and I had also tried defining a new cache directory, which also didn't make any difference. On Fri, Apr 5, 2019 at 2:35 PM Colin Percival wrote: > In addition to Graham's comments about debugging the network... > > On 4/4/19 7:20 PM, Julian Lam wrote: > > Seems I'm running out of money on my account, so I wanted to go ahead > and nuke > > what I had, except I'm unable to at this time: > > > > /usr/bin/tarsnap --key tarsnap.key --cachedir .tarsnap-cache --fsck > > If you want to nuke *all* of your archives, you don't need to run --fsck. > You only need to have a synchronized cache directory for creating new > archives or deleting *individual* archives (since that's how tarsnap > figures out which blocks are no longer needed -- not an issue if you ask > to delete everything). > > -- > Colin Percival > Security Officer Emeritus, FreeBSD | The power to serve > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid >
Tarsnap connection lost, not sure how to debug
Seems I'm running out of money on my account, so I wanted to go ahead and nuke what I had, except I'm unable to at this time: /usr/bin/tarsnap --key tarsnap.key --cachedir .tarsnap-cache --fsck tarsnap: Connection lost, waiting 30 seconds before reconnecting ^C --print-stats outputs: tarsnap: Error reading cache directory from /root/.tarsnap-cache tarsnap: Error generating archive statistics tarsnap: Error exit delayed from previous errors. Not quite sure how to debug... so far I've reinstalled tarsnap via the deb package, but that didn't work.
