Date: Fri, 5 Mar 2010 00:21:10 +1030 From: Malcolm Kay <malcolm.kay@internode.on.net> To: krad <kraduk@googlemail.com> Cc: freebsd-questions@freebsd.org Subject: Re: / slice too small Message-ID: <201003050021.10356.malcolm.kay@internode.on.net> In-Reply-To: <d36406631003040153k775e5993p49d226be1df3b782@mail.gmail.com> References: <20100228132654.GA2796@orange.esperance-linux.co.uk> <201003041221.30263.malcolm.kay@internode.on.net> <d36406631003040153k775e5993p49d226be1df3b782@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Mar 2010 08:23 pm, krad wrote: > 2010/3/4 Malcolm Kay <malcolm.kay@internode.on.net> > > > On Thu, 4 Mar 2010 02:44 am, krad wrote: > > > On 3 March 2010 14:23, Malcolm Kay > > > > <malcolm.kay@internode.on.net> wrote: > > > > On Mon, 1 Mar 2010 08:44 am, krad wrote: > > > > > On 28 February 2010 15:42, Elias Chrysocheris > > > > > > > > <eliaschr@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003050021.10356.malcolm.kay>