Re: Unanticipated time and costs for full recovery

[Craig <craig.lists@subs4.sitnominedigna.com>]

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.