[clug] Story: Fijian Resort complex loses a single disk: business process stops for 1-2 days

[Scott Ferguson]

On 28/07/14 11:01, Bob Edwards wrote:
> On 27/07/14 16:26, Scott Ferguson wrote:
>>
>> I'm biased against Apple/Closed source, and most of my experience with
>> Time Machine is when I've had to recover backups (using rsync) when it's
>> eaten clients backups :(    (see attached for the most common TM fail)
>>
> 
> I notice in jwz's article, referenced by Hal, that he implicitly doesn't
> endorse Time Machine, even as somewhat of a Mac Fanboy himself (and
> what he has to say about Window's users doesn't bear repeating... maybe
> a case of residual bitterness after the Browser wars...). I like how
> jwz ends his article - even if I don't agree with it to the letter...
> 
> I completely agree (with Scott) that relying on a proprietary system to
> backup data that is valuable enough to be backed up is a bad solution.
> 
> Cheers,
> 
> Bob Edwards.


That wouldn't be my main critique - more of disclaimer. Technically
hard/multi-links and fsevents seems not-as-bad as some other systems
(I'm surprised it's so slow for AS, sparse mode off?), and it gets
points for being part of the system *and* having an intuitive interface.
I'd 'speculate' that more Apple user do some sort of backup with it than
Windoof users as a result - which is a not-so-terrible thing.

Similar functionality and simple interface can be achieved with
BackInTime, various implementation of duplicity are technically superior
(IMO) - however they still have the same critical weakness *if* that the
backup system is part of the system being backed up (be your own
psychiatrist? what could go wrong?).
That reads like I approve of partial solutions (and good intentions) -
which I don't, but any effort is less-worse than none. However - the
more you backup, the longer you'll use 'it', the more 'it' will become
important, the more data you'll accumulate, the more you'll forget
critical information when you need to restore 'it' - and the more likely
that something will go seriously wrong (to the point where it's
inevitable that a single restore will fail to do just that). e.g. close
to a PiB of encrypted backups that will only restore on specific
hardware (that was stolen - "it was a server, HP, or maybe Dell,
definitely gray"), and all the keys are encrypted in the backup -
including the documentation for the backup procedures. Backup media
intact, data intact, backups useless.

A backup system that works the way it's planned - when the plan is to
restore from unplanned events, at a unknown time in an unknown future,
is a challenging exercise.

Kind regards


--

I guess all I know is
I don't know what I don't know
Everything is obvious, when I know how it works