Hi Graham, Thanks. I guess I'd copy what I have recovered to another location first, because I don't want to risk what has been recovered.
I haven't done anything with Redsnapper yet, including installing it and whatever its prerequites are, so that's next on my life. Craig On Tue, 2025-08-12 at 12:26 -0700, Graham Percival wrote: > Hi, > > I'm not able to comment about most of this email, but regarding > "restarting my back-up recovery", I recommend using: > > --resume-extract > (x mode only) Don't extract files whose filesize and mtime > matches existing files on the disk. Primarily used to resume > an > archive extraction which was interrupted. The mtime > comparison > ignores sub-second timestamp precision, as this is not > supported > on all filesystems. This differs from -k in that > --resume-extract will overwrite a file if the size or > modification time do not match, as can happen if tarsnap is > killed partway through extracting a file. > > > ... I was about to add "but of course Redsnapper does this already", > but > based on a quick search of their github repository, they don't seem > to > use --resume-extract (which was added in tarsnap 1.0.40 on 2022-02- > 10, > after the latest rednapper release). > > Regards, > - Graham > > On 2025-08-12, Craig wrote: > > Hi there, > > > > I've completely rewritten this message twice because the first > > version > > sounded too whiney and the second version is stale having sat > > unsent > > for most of two months. This one probably will probably sound > > whiney as > > well, but just imagine then what the first version sounded like! > > This > > version also includes a suggestion, as well as my question. > > > > I've never done a full data recovery before because I never thought > > I'd > > be stupid enough to need to. Apparently I'm wrong. A single file > > here > > and there? Sure, but not my whole collection of data created and > > saved > > over the course of forty-five odd years. (Thank the gods I backed > > it up > > despite knowing I was so smart.) But the reason I need to do a full > > recovery is not because my house burned down or because that > > experiment > > of swimming with my hard drive didn't work, but because LUKS > > decided > > that my password didn't work any more. Imagine that! If you want to > > cure someone of using encryption to save their data, just decide to > > deny their password that was working over multiple operating > > systems > > every day for over a decade. Now I'm in the class of people that > > "claim" they didn't lose their password, but we all know the truth, > > nudge nudge, wink wink. > > > > But I am annoyed because I didn't think I'd have to re-mortgage the > > house that didn't burn down to recover my ~350 GB of data. (I had > > chosen not to back-up some stuff because it wasn't "vital", but I'm > > going to miss that stuff anyway that I wasn't willing to pay for, > > because I knew that when my house burned down I'd just be thankful > > I > > got the "vital" stuff back.) I suppose not knowing how much my > > recovery > > would cost is my own fault, because obviously 350 GB x $0.25/GB is > > a > > little more than the $55 that was in my account after recently > > topping > > it up. So my bad that the recovery failed after 92 hours on a cable > > connection when, shock of all shocks, my balance ran out. > > > > But 92 hours for just *some* of my data?! (That's just under four > > full > > sleeps, in case that's not obvious.) I obviously didn't get all 350 > > GB, > > but even if the last byte managed to slip through just as my > > balance > > hit zero at the 92-hour mark, that's a download rate of 350 GB per > > 92 > > hours, or 3.8 GB per hour ... and *significantly* less than 350 GB > > got > > through so, of course, the *rate* was *significantly* slower. > > Although > > I don't know enough to write or understand formulae like "O(N log N > > + N > > · M log M)", I know that 3.8 GB per hour is *significantly* slower > > than > > the download speed I just tested/measured of 93 Mbps. (I feel the > > need > > to state that I know the difference between a bit and a byte.) > > > > Bottom line is I'm going to have to re-start my recovery based on > > actually thinking (what a concept!) about how much it will cost to > > get > > 350 GB back. I will add double that amount to my account, and then > > add > > another $55 for what I usually pay in a month. Hopefully that will > > more > > than cover it. > > > > To address the time for recovery problem -- about which I was > > vaguely > > aware before, but not acutely as I am now -- I will use the > > apparently > > only somewhat reasonable alternative out there, which seems to be > > Redsnapper. I just never thought about recovering *all* my data > > because, as I said, I'm way too smart to lose all my data. > > > > QUESTION > > > > My only question at this point, having got the background out of my > > system, is this: Is it possible to restart my back-up recovery from > > the > > point at which it failed so that I don't have to thrown out the > > approximately $55 I've already spent bringing down the data I have > > already paid to bring down? (Pardon my redundancy.) Or do I have to > > start again from scratch and waste/spend that $55 again? > > > > ----- > > > > Thanks. > > > > > > Craig > > > > > > P.S.: A code suggestion: The command to recover a full back-up is, > > "tarsnap -x -f ARCHIVE-NAME", while the command to recover a single > > file or directory is, "tarsnap -x -f ARCHIVE-NAME > > path/to/file.ext". > > While I don't usually suggest or encourage hand-holding, it seems > > to me > > that if the former command is used "tarsnap" should do one of two > > things: (1) Pause the execution to ask, "Are you sure your account > > balance will support recovering the full archive at $0.25 per GB?", > > to > > which the user should respond y/n after checking their account > > (and, if > > necessary, topping it up); or, (2), if "tarsnap" has access to the > > user's balance it could make a more intelligent judgement. It has > > occurred to me in the past that "tarsnap" having access to an > > account's > > balance (for option 2) would be a good idea for the same reason > > that > > "your balance is a week away from zero" emails are sent; I've seen > > complaints from people saying that they didn't know their balance > > was > > approaching zero because (for some reason) they don't read messages > > sent to their account's email address (which seems bizarre), but if > > they read their messages sent by their cron job they might see a > > message like, "Your balance is near zero." Just an idea.
