Date: Sun, 31 Oct 2010 13:44:25 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: perryh@pluto.rain.com Cc: cronfy@gmail.com, freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? Message-ID: <201010312044.o9VKiPwG049615@apollo.backplane.com> References: <AANLkTikzZvZn=vNNRtcSViWq8ty7b8qOooQ4NbHiJH5q@mail.gmail.com> <AANLkTikpk4O-q_Omh9eAGZB474J1BVu2YJ7OKWvhZm7v@mail.gmail.com> <4ccceb10.4n2iAQ/sY/YrDSI2%perryh@pluto.rain.com> <201010311635.o9VGZG1O046164@apollo.backplane.com> <4ccdcdaa.XSDkZZUUYXDXpkXV%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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.
There is a certain convenience to being able to restore a file from
a live backup in a few seconds verses having to struggle with large
multi-layered incremental dump/restore files that were designed to be
spooled off to tape units.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010312044.o9VKiPwG049615>