On Thu, 4 Mar 2010 08:23 pm, krad wrote: > 2010/3/4 Malcolm Kay <malcolm....@internode.on.net> > > > On Thu, 4 Mar 2010 02:44 am, krad wrote: > > > On 3 March 2010 14:23, Malcolm Kay > > > > <malcolm....@internode.on.net> wrote: > > > > On Mon, 1 Mar 2010 08:44 am, krad wrote: > > > > > On 28 February 2010 15:42, Elias Chrysocheris > > > > > > > > <elias...@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. Regards, Malcolm _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"