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: > > > > > On Sunday 28 of February 2010 15:26:54 Frank Shute wrote: > > > > > > I've got a machine here running 7.2 which I want to > > > > > > upgrade to 8.0 but looking at the root slice it is > > > > > > woefully small: > > > > > > > > > > > > $ df -h > > > > > > Filesystem Size Used Avail Capacity Mounted > > > > > > on /dev/ad4s2 190M 146M 29M 84% / > > > > > > devfs 1.0K 1.0K 0B 100% /dev > > > > > > /dev/ad4s4 129G 15G 104G 12% /usr > > > > > > devfs 1.0K 1.0K 0B 100% > > > > > > /var/named/dev > > > > > > > > > > > > I've got a CD/DVD writer on that machine along with a > > > > > > 100MB ethernet connection to my desktop. > > > > > > > > > > > > How do I go about upgrading it? Dump/restore and > > > > > > change the partition table? > > > > > > > > > > > > Any suggestions gratefully received. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Yes. The dump/restore should do the trick as long as you > > > > > have another medium > > > > > to store the dumps (such as another hard disk). You will > > > > > store the images of > > > > > your slices to the new medium using dump(8). You can > > > > > then use FixIt console to > > > > > re-partition and re-slice your hard disk and then > > > > > restore(8) your images in the newly sliced hard disk. > > > > > Actually, if you have another hard disk device, you can > > > > > use piped dump/restore to copy the whole system from one > > > > > disk to the other and make the second one your bootable > > > > > disk. Of course you must have sliced the second device > > > > > first. > > > > > I've done this many times. The first was to remove an > > > > > openSUSE partition I had, > > > > > living in the same hard disk as my FreeBSD. The second > > > > > time was to move my FreeBSD to another hard disk > > > > > (physical device). The new disk became my boot disk. > > > > > The third time was to move my system to another bigger > > > > > hard disk device and at > > > > > the same time be formated as ZFS. > > > > > Now my system boots from this third hard disk device, > > > > > having ZFS and the operating system is the same as that > > > > > I first installed (of cource updated...) > > > > > > > > > > Elias > > > > > _______________________________________________ > > > > > freebsd-questions@freebsd.org mailing list > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questi > > > > >ons To unsubscribe, send any mail to " > > > > > freebsd-questions-unsubscr...@freebsd.org" > > > > > > > > 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. > But each to his own; backup methods and strategies have always > been something of a controverial issues. > > > > > > Malcolm Kay > > > > > > > I use it in our backup setup at work, and have restored > > > > countless freebsd boxes. > > > > > > > > When you repartition the drive remember to add the boot > > > > blocks > > > > > > > > eg > > > > > > > > fdisk -B ad0 > > > > bsdlabel -B ad0s1 > > > > _______________________________________________ > > > > freebsd-questions@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-question > > > >s To unsubscribe, send any mail to > > > > "freebsd-questions-unsubscr...@freebsd.org" > > > > > > _______________________________________________ > > > 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" > _______________________________________________ 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"
