On 12/24/06, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Dec 18, 2006 at 03:47:42AM +0100, Molle Bestefich wrote:
>
> [...]
>
> > Simply put, a tool with just a single button named "recover
> > all the data that you can" is by far the best solution in so
> > many cases. Minimal fuzz, minimal downtime, minimal money
> > spent on recovery. And perhaps there's even a good chance that
> > any missing data could be entered back into the system manually.
>
> I think the point which has been made here was that the recovery tool
> *is already there*: i.e. all what can be done as an "one-click" recovery
> is done by the system at start-up. Beyond this no cookbook exists (and
> thus no way to put it under an one-click procedure).
>
> So this one-click thing would be mainly something to cater for the
> "needs" of marketing.
Well start-up recovery is great and reliable. The only problem is that
it won't help if you have some obscure hardware problem, you really
have a problem. If you want to sleep well, you should know what to
do when disaster happens.
I really like the approach of XFS filesystem, which ships with fsck.xfs
which is essentially equivalent to /bin/true. They write in their white
paper that they did so, because journaling should recover from all
failures. Yet they also wrote that some time after they learned that
hardware corruption is not as unlikely as one might assume, so they
provide xfs_check an xfs_repair utilities.
I think there should be a documented way to recover from obscure
hardware failure, with even more detailed information how this could
result only from using crappy hardware... And I don't think this should
be "one click" process -- some people might miss real (software)
corruption, and this is a biggest drawback. Perhaps the disaster
recoverer should leave a detailed log which would be enough to
detect software-corruption even after the recovery [and users should
be advised to send them].
Regards, Dawid Kuroczko