/ slice too small
malcolm.kay at internode.on.net
Thu Mar 4 13:51:14 UTC 2010
On Thu, 4 Mar 2010 08:23 pm, krad wrote:
> 2010/3/4 Malcolm Kay <malcolm.kay at internode.on.net>
> > On Thu, 4 Mar 2010 02:44 am, krad wrote:
> > > On 3 March 2010 14:23, Malcolm Kay
> > <malcolm.kay at internode.on.net> wrote:
> > > > On Mon, 1 Mar 2010 08:44 am, krad wrote:
> > > > > On 28 February 2010 15:42, Elias Chrysocheris
> > > >
> > > > <eliaschr at cha.forthnet.gr>wrote:
> > > > >
> > > > > You might well find it easier to use rsync rather than
> > > > > dump. Just make sure you use the following flags
> > > > >
> > > > > rsync -aHP --numeric-ids
> > > >
> > > > This is a bit questionable for copying live fs. Probably
> > > > OK if you use snapshots. Leaves you in very similar
> > > > situation as doing backups with tar. These schemes also
> > > > alter the access times on files (which I guess doesn't
> > > > usually matter too much).
> > > >
> > > > But dump/restore is no more complex to use than rsync
> > > > and manages snapshots for you, so why mess about with
> > > > questionable schemes.
> > >
> > > I understand what you mean about live file systems, but in
> > > this case its not a problem as he will be in single user
> > > mode.
> > I'm not sure that single user mode avoids this problem.
> > > Also using the "a" flag means the modification times are
> > > intact.
> > I did not mention modification times but access times which
> > I admit are seldom put to any use. It is very difficult for
> > any utility to avoid altering these -- dump is the only
> > exception I know of.
> > Sorry i misread
> > > I use rsync at work over 100s of systems and it is very
> > > effective, and the noc find it far easier to recover small
> > > numbers of files than having to go digging into dump
> > > files.
> > I've not found this too difficult even when working with
> > compressed dumps.
> > > The way we have got everything setup on a zfs backend mean
> > > we can do incremental forever, as well which is much more
> > > efficient than having to do regular level 0 dumps.
> > Yes, rsync is great for updating incremental changes but
> > this is quite irrelevant to the OP's problem.
> > For backup it seems this also somewhat reduces the
> > effectiveness. For example when you are asked to recover the
> > original of a file that was changed before the lastest
> > backup. Many of us think it desirable to regularly archive
> > complete backups.
> This is not a problem in our scenario as the backend storage
> is zfs and all underpinned with snapshots. This enables us to
> retrieve and file from any day for the last x days dependent
> on the retention period.
Sounds good. I have no experience with zfs. But I suggest that
'x' needs to be quite large.
Anyway I think we (or rather I) have done the subject to death,
and it is time for me to keep quiet.
More information about the freebsd-questions