[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unanticipated time and costs for full recovery



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.
> 
> 
>