steve@avalon.dartmouth.edu (Steve Campbell) (03/19/90)
Having a disk partition table on each disk pack (see chpt(8)) is a great improvement over having the partition layout coded into the driver, but there is one little drawback. It used to be possible to make backup copies of the root partition, 0a, by using dd(1) to copy /dev/r??0a to /dev/r??1a or any other "a" partition. This was fast (less than a minute on RA81's) and on several occasions saved me many hours of work. But now with the disk partition table in the superblock, you can't use dd(1) this way unless the two disks have identical partition tables, since the tables get copied, too, and... I haven't yet found a good alternative for making disk-to-disk copies of the root file system. Pipes using tar(1) or dump/restore are much slower and have other disadvantages like too much operator intervention being required. Does anyone have any suggestions? Steve Campbell Dartmouth College
grr@cbmvax.commodore.com (George Robbins) (03/19/90)
In article <20692@dartvax.Dartmouth.EDU> steve@avalon.dartmouth.edu (Steve Campbell) writes: > Having a disk partition table on each disk pack (see chpt(8)) is a great > improvement over having the partition layout coded into the driver, but > there is one little drawback. It used to be possible to make backup > copies of the root partition, 0a, by using dd(1) to copy /dev/r??0a to > /dev/r??1a or any other "a" partition. This was fast (less than a minute > on RA81's) and on several occasions saved me many hours of work. But now > with the disk partition table in the superblock, you can't use dd(1) this > way unless the two disks have identical partition tables, since the > tables get copied, too, and... > > I haven't yet found a good alternative for making disk-to-disk copies > of the root file system. Pipes using tar(1) or dump/restore are much > slower and have other disadvantages like too much operator intervention > being required. Does anyone have any suggestions? Yes, this is a problem. The simple solution is just to standardize on parition sizes and drive types, at least between the system disk and the place you like to do your root backups. I usually do an occasional tape dump and restore, but have used a pipe on occasion. For a normal (7 or 15MB) root parition it's not that slow, and as far as I can remember doesn't require any "operator intervention"... #! /bin/sh umount blah newfs blah blah mount blah dump 0f - / | (cd blah; restore rf -) done? restore r is silent, restore x asks silly questions. 8-) -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
avolio@decuac.DEC.COM (Frederick M. Avolio) (03/20/90)
We use a shell script executed out of crontab. Uses dump. Doesn't require operator intervention. Fred -------------- 0 18 * * * /usr/adm/manager/rootbkup /usr/adm/manager/rootbkup is: #!/bin/sh # back up root to spare partition nightly -- avolio # mount /dev/ra7a /bck if test $? -ne 0 then echo problem mounting ra7a -- rootbkup not done| mail manager exit 1 fi umount /dev/ra7a newfs /dev/rra7a ra81 if test $? -ne 0 then echo newfs /dev/rra7a ra81 failed in rootbkup | mail manager exit 2 fi mount /dev/ra7a /bck if test $? -ne 0 then echo mount of /dev/ra7a after newfs failed in rootbkup | mail manager exit 3 fi cd / dump 0uf - / | (cd /bck ; restore xf -) >/dev/console cd / umount /dev/ra7a echo Auto-dump of root to bck done `date` |tee -a /usr/adm/opslog >/dev/console exit
parker@zaphod.mpr.ca (Ross Parker) (03/20/90)
In article <10238@cbmvax.commodore.com>, grr@cbmvax.commodore.com (George Robbins) writes: > In article <20692@dartvax.Dartmouth.EDU> steve@avalon.dartmouth.edu (Steve Campbell) writes: > > It used to be possible to make backup > > copies of the root partition, 0a, by using dd(1) to copy /dev/r??0a to > > /dev/r??1a or any other "a" partition. This was fast (less than a minute > > on RA81's) and on several occasions saved me many hours of work. But now > > with the disk partition table in the superblock, you can't use dd(1) this > > way unless the two disks have identical partition tables, since the > > tables get copied, too, and... > Yes, this is a problem. The simple solution is just to standardize on > parition sizes and drive types, at least between the system disk and the > place you like to do your root backups. > > I usually do an occasional tape dump and restore, but have used a pipe on > occasion. For a normal (7 or 15MB) root parition it's not that slow, and > as far as I can remember doesn't require any "operator intervention"... > > #! /bin/sh > umount blah > newfs blah blah > mount blah > dump 0f - / | (cd blah; restore rf -) One additional 'gotcha' about the 'dd' method of copying a root partition: If you're doing this on a BA123 Microvax-II, even if your partition tables are the same, you can be in for a fair bit of work if you ever have a power outage (and who doesn't :-( ). We used to do this, until I found out (the hard way, of course) that the BA123 does something slightly goofy when running power-up system checks, namely, it checks each RD-type drive in sequence from the *high* numbered drive down to the *low* numbered drive (eg. unit 0), and if it finds a bootable pack (or what it deems bootable - presumably a disk with a boot block), it will not check and will *LEAVE OFFLINE* any lower-numbered disks. When this happened to us, we luckily had a DEC hardware guy in (doing something else) - he was as mystified as we were at first, but after many phone calls he finally found someone else at DEC who agreed that this was normal operation for the BA123. I don't know exactly what needs to be on the disk to cause the problem... just making a file system on the 'a' partition will by default copy a boot block there, so that can't be the only factor. It may be a combination of this and some other factor (certainly the system doesn't understand what '/vmunix' is when doing power-up checks) that causes the bizarre behaviour. All I know is that it took myself and our DEC guy about three hours to finally figure out what the problem was. I now use George's suggested method of dumping the root file system when I want an on-line root backup (which isn't too often...). Ross Parker parker@mpre.mpr.ca (604)293-5495 uunet!ubc-cs!mpre!parker