Date: Mon, 1 Nov 2010 09:16:58 +0200 From: Jonathan McKeown <j.mckeown@ru.ac.za> To: freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? Message-ID: <201011010916.59108.j.mckeown@ru.ac.za> In-Reply-To: <201010312044.o9VKiPwG049615@apollo.backplane.com> References: <AANLkTikzZvZn=vNNRtcSViWq8ty7b8qOooQ4NbHiJH5q@mail.gmail.com> <4ccdcdaa.XSDkZZUUYXDXpkXV%perryh@pluto.rain.com> <201010312044.o9VKiPwG049615@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 31 October 2010 22:44:25 Matthew Dillon wrote: > :> and the output produced by dump is not live-accessible whereas a > :> snapshot / live filesystem copy is. That makes the dump fairly > :> worthless for anything other than catastrophic recovery. > : > :Ever heard of "restore -i"? > > Have you ever tried to restore a single file from a 2 Terrabyte dump > file ? Or even better, if you are using incremental dumps, try > restoring a single file from 6 dump files. > > I'm not saying that dump/restore is completely unusable, I'm saying > that it MOSTLY unusable for the use cases people have today for > backups. I'd argue that if you're routinely restoring single files, you aren't managing your time or your users' expectations properly. Backups are /for/ catastrophic recovery, imo, and users shouldn't expect systems staff to be routinely restoring single files they've inadvertently deleted. Users need to realise that when you delete something it goes away: that's what delete does, which is why you're usually asked to confirm it. Restoring single files for individual users should be very much a special case and not a routine service; otherwise you risk being snowed under with file recovery requests. Jonathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011010916.59108.j.mckeown>