Re: Dump Restore on ZFS root system
On 07/02/2012 11:00, dick wrote: I run a ZFS on root FreeBSD system. I know I can backup with snapshots but I want a dump/restore action because I want to transfer this system to a UFS virtual FreeBSD machine. My question is: will dump / (root) make a dump of *ALL* other directories? Dump works at the filesystem level and will not work on a zfs filesystem [root@banshee /backup/local/zfs]# dump -b 64 -f - ./ dump: ./: unknown file system I'd use tar or cpio or pax or something. On a UFS filesystem dump will only dump the filesystem specified and will not cross mountpoints. Vince yanta# df -h Filesystem SizeUsed Avail Capacity Mounted on zroot56G335M 55G 1%/ devfs1.0K1.0K 0B 100%/dev zroot/tmp56G 42M 55G 0%/tmp zroot/usr 60G4.7G 55G 8%/usr zroot/usr/home 58G2.4G 55G 4%/usr/home zroot/usr/ports 56G253M 55G 0% /usr/ports zroot/usr/ports/distfiles56G291M 55G 1% /usr/ports/distfiles zroot/usr/ports/packages 55G 21K 55G 0% /usr/ports/packages zroot/var 56G571M 55G 1%/var zroot/var/crash 55G 23K 55G 0% /var/crash zroot/var/db56G337M 55G 1%/var/db zroot/var/db/pkg55G3.7M 55G 0%/var/db/pkg zroot/var/empty 55G 21K 55G 0%/var/empty zroot/var/log 55G827K 55G 0% /var/log zroot/var/mail 55G 22K 55G 0% /var/mail zroot/var/run 55G 53K 55G 0% /var/run zroot/var/tmp 55G143K 55G 0%/var/tmp devfs 1.0K1.0K 0B 100%/var/named/dev ___ 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
Re: Dump Restore on ZFS root system
Op 7-2-2012 12:23, Vincent Hoffman schreef: On 07/02/2012 11:00, dick wrote: I run a ZFS on root FreeBSD system. I know I can backup with snapshots but I want a dump/restore action because I want to transfer this system to a UFS virtual FreeBSD machine. My question is: will dump / (root) make a dump of *ALL* other directories? Dump works at the filesystem level and will not work on a zfs filesystem [root@banshee /backup/local/zfs]# dump -b 64 -f - ./ dump: ./: unknown file system I'd use tar or cpio or pax or something. On a UFS filesystem dump will only dump the filesystem specified and will not cross mountpoints. OK, got it. I will have to read up on the best option (tar, cpio or pax) ___ 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
Re: Dump Restore on ZFS root system
On Tue, Feb 7, 2012 at 1:55 PM, dick d...@nagual.nl wrote: Op 7-2-2012 12:23, Vincent Hoffman schreef: On 07/02/2012 11:00, dick wrote: I run a ZFS on root FreeBSD system. I know I can backup with snapshots but I want a dump/restore action because I want to transfer this system to a UFS virtual FreeBSD machine. My question is: will dump / (root) make a dump of *ALL* other directories? Dump works at the filesystem level and will not work on a zfs filesystem [root@banshee /backup/local/zfs]# dump -b 64 -f - ./ dump: ./: unknown file system I'd use tar or cpio or pax or something. On a UFS filesystem dump will only dump the filesystem specified and will not cross mountpoints. OK, got it. I will have to read up on the best option (tar, cpio or pax) You can always clone it using zfs send / receive to your vm: http://www.aisecure.net/2011/03/26/cloning-a-zfs-bootable-system/ -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net ___ 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
Re: Dump Restore on ZFS root system
On 07/02/2012, at 22:25, dick wrote: Op 7-2-2012 12:23, Vincent Hoffman schreef: On 07/02/2012 11:00, dick wrote: I run a ZFS on root FreeBSD system. I know I can backup with snapshots but I want a dump/restore action because I want to transfer this system to a UFS virtual FreeBSD machine. My question is: will dump / (root) make a dump of *ALL* other directories? Dump works at the filesystem level and will not work on a zfs filesystem [root@banshee /backup/local/zfs]# dump -b 64 -f - ./ dump: ./: unknown file system I'd use tar or cpio or pax or something. On a UFS filesystem dump will only dump the filesystem specified and will not cross mountpoints. OK, got it. I will have to read up on the best option (tar, cpio or pax) ___ 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 Why not use the ZFS send / receive command? Sincerely, William Brown Research Teaching, Technology Services The University of Adelaide, AUSTRALIA 5005 CRICOS Provider Number 00123M - IMPORTANT: This message may contain confidential or legally privileged information. If you think it was sent to you by mistake, please delete all copies and advise the sender. For the purposes of the SPAM Act 2003, this email is authorised by The University of Adelaide. pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Dump Restore on ZFS root system
On Tue, 7 Feb 2012, dick wrote: Op 7-2-2012 12:23, Vincent Hoffman schreef: On 07/02/2012 11:00, dick wrote: I run a ZFS on root FreeBSD system. I know I can backup with snapshots but I want a dump/restore action because I want to transfer this system to a UFS virtual FreeBSD machine. My question is: will dump / (root) make a dump of *ALL* other directories? Dump works at the filesystem level and will not work on a zfs filesystem [root@banshee /backup/local/zfs]# dump -b 64 -f - ./ dump: ./: unknown file system I'd use tar or cpio or pax or something. On a UFS filesystem dump will only dump the filesystem specified and will not cross mountpoints. OK, got it. I will have to read up on the best option (tar, cpio or pax) Or rsync, with -a, -H, and probably some other options I can't recall. ___ 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
Re: dump/restore, how to reduce slice size
# df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ad4s1a 2G206M1.6G11%/ devfs 1.0k1.0k 0B 100%/dev /dev/ad4s1e3.9G 13M3.6G 0%/tmp /dev/ad4s1f 40G 25G 12G67%/usr /dev/ad4s1d 31G3.6G 24G13%/var procfs 4.0k4.0k 0B 100%/proc /dev/ad2s1f 39G 25G 10G71%/mnt devfs 1.0k1.0k 0B 100%/var/named/dev as you can see /dev/ad4s1f is 40G and /dev/ad2s1f is 39G but on ad4s1f only 25G used. How can I dump /dev/ad4s1f and restore it on /dev/ad2s1f? You can't. ad4s1f has 25G of files, but ad2s1f only has 10G of free space. You need a bigger disk. If you're just moving things around, I agree that a $100 USB disk is the best way to store backups temporarily. R's, John ___ 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
Re: dump/restore, how to reduce slice size
On Fri, Sep 30, 2011 at 03:41:26PM +0200, Damien Fleuriot wrote: On 9/29/11 10:09 PM, Jerry McAllister wrote: On Thu, Sep 29, 2011 at 10:36:38PM +0300, ??? ??? wrote: Hi, Freebsd-questions. # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ad4s1a 2G206M1.6G11%/ devfs 1.0k1.0k 0B 100%/dev /dev/ad4s1e3.9G 13M3.6G 0%/tmp /dev/ad4s1f 40G 25G 12G67%/usr /dev/ad4s1d 31G3.6G 24G13%/var procfs 4.0k4.0k 0B 100%/proc /dev/ad2s1f 39G 25G 10G71%/mnt devfs 1.0k1.0k 0B 100%/var/named/dev as you can see /dev/ad4s1f is 40G and /dev/ad2s1f is 39G but on ad4s1f only 25G used. How can I dump /dev/ad4s1f and restore it on /dev/ad2s1f? These commands: #mount /dev/ad2s1f /mnt #cd /mnt #dump -0Lf - /usr | restore -rf - does not help, because of ad2s1f does not have space to restore 'end of ' /dev/ad4s1f. May help any? Well, you are going to have difficulty putting 50 GB on a 39 GB partition. (25GB + 25GB = 50GB). It won't work. You could try compressing the dump, but dump files do not tend to compress well and even if you got a 50% compression, you would still be really close to overfill. Probably you need to go to the store and get a nice big USB drive and slice and partition it in to a bunch of 50 GB partitions and pipe your dump to a restore in those partitions on that drive. You can round-robin your backups to those USB partitions. My backup to a USB hard drive just saved me the beginning of this week when the old machine died of heat prostration. Dump is supposed to take only the used space. Yes. He already has 25 GB used on the partition and wants to add another approx 25 GB in a 39 GB partition. There ain't room. jerry @OP, refer the following link for correct dump/restore syntax: http://www.wonkity.com/~wblock/docs/html/backup.html#_tt_dump_tt_with_compression ___ 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
Re: dump/restore, how to reduce slice size
On Thu, Sep 29, 2011 at 10:36:38PM +0300, ??? ??? wrote: Hi, Freebsd-questions. # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ad4s1a 2G206M1.6G11%/ devfs 1.0k1.0k 0B 100%/dev /dev/ad4s1e3.9G 13M3.6G 0%/tmp /dev/ad4s1f 40G 25G 12G67%/usr /dev/ad4s1d 31G3.6G 24G13%/var procfs 4.0k4.0k 0B 100%/proc /dev/ad2s1f 39G 25G 10G71%/mnt devfs 1.0k1.0k 0B 100%/var/named/dev as you can see /dev/ad4s1f is 40G and /dev/ad2s1f is 39G but on ad4s1f only 25G used. How can I dump /dev/ad4s1f and restore it on /dev/ad2s1f? These commands: #mount /dev/ad2s1f /mnt #cd /mnt #dump -0Lf - /usr | restore -rf - does not help, because of ad2s1f does not have space to restore 'end of ' /dev/ad4s1f. May help any? Well, you are going to have difficulty putting 50 GB on a 39 GB partition. (25GB + 25GB = 50GB). It won't work. You could try compressing the dump, but dump files do not tend to compress well and even if you got a 50% compression, you would still be really close to overfill. Probably you need to go to the store and get a nice big USB drive and slice and partition it in to a bunch of 50 GB partitions and pipe your dump to a restore in those partitions on that drive. You can round-robin your backups to those USB partitions. My backup to a USB hard drive just saved me the beginning of this week when the old machine died of heat prostration. jerry jerry -- Konkov mailto:kes-...@yandex.ru ___ 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
Re: Dump/restore to clone disk
On Mon, 22 Feb 2010 16:33:47 +0800, Aiza aiz...@comclark.com wrote: I have seen this posted in the questions archives to be used to clone a active system hard drive to a USB cabled hard drive. Prepare the target #dd if=/dev/zero of=/dev/da0 count=2 # fdisk -BI /dev/da0 # bsdlabel -B -w da0s1 # newfs –U /dev/da0s1a # / # newfs -U /dev/da0s1d # /var # newfs -U /dev/da0s1e # /tmp # newfs -U /dev/da0s1f # /usr Mount target file system ‘a’ # mount /dev/da0s1a /mnt # cd /mnt # dump -0Lauf - /dev/ad1s1a | restore -rf - # cd / # umount /mnt Mount target file system ‘d’ # mount /dev/da0s1d /mnt # cd /mnt # dump -0Lauf - /dev/ad1s1d | restore -rf - # cd / # umount /mnt Mount target file system ‘e’ # mount /dev/da0s1e /mnt # cd /mnt # dump -0Lauf - /dev/ad1s1e | restore -rf - # cd / # umount /mnt Mount target file system ‘f’ # mount /dev/da0s1f /mnt # cd /mnt # dump -0Lauf - /dev/ad1s1f | restore -rf - # cd / # umount /mnt I'd like to suggest successive mounting of the partitions. E. g. as they are nested on the source disk, this can be done on the target disk, too. # mount /dev/ad1s1a /mnt # cd /mnt # dump -0 -f - /dev/ad0s1a | restore -r -f - # mount /dev/ad1s1e /mnt/tmp # cd /mnt/tmp # dump -0 -f - /dev/ad0s1e | restore -r -f - # mount /dev/ad1s1f /mnt/var # cd /mnt/var # dump -0 -f - /dev/ad0s1f | restore -r -f - # mount /dev/ad1s1g /mnt/usr # cd /mnt/usr # dump -0 -f - /dev/ad0s1g | restore -r -f - # mount /dev/ad1s1h /mnt/home # cd /mnt/home # dump -0 -f - /dev/ad0s1h | restore -r -f - And then: # cd / # umount /mnt/home # umount /mnt/usr # umount /mnt/var # umount /mnt/tmp # umount /mnt # sync # halt In the above example, transfer is going from ad0 to ad1. I have questions about this method. What happened to swap? The fstab will be showing it as the first file system on the hard drive slice. Is something missing here? The swap partition does not need to be cloned. Furthermore, I doubt that it is the first partition on the disk, while it MAY be possible that it is the first entry in /etc/fstab. The root partition usually refers to partition a, while the swap partition refers to b. What about the file system sizes. Will the restored hard drive have the same file system sizes as the source file system? The target partitions should be at least as big as the source partitions, and they will be filled up to the point the source partition has data, e. g. partition /usr is 20 GB and has 10 GB data, and it is dumped and restored to a new /usr partition with 30 GB space available, then this new partition will be occupied 1/3 (with 10 GB). Is there some way to allocate larger file systems on the target without using sysinstall to prepare the target beforehand? Yes, sade is such a tool, as well as the usual method of using fdisk, bsdlabel, and newfs. Is there some command to display the file system allocation size? You can always use df -h for this, e. g. % df -h /var Filesystem SizeUsed Avail Capacity Mounted on /dev/ad0s1e989M384M527M42%/var THis should inspire you how to dimension the new partition. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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
Re: Dump/restore to clone disk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/02/2010 08:33, Aiza wrote: What happened to swap? The fstab will be showing it as the first file system on the hard drive slice. Is something missing here? Swap isn't a filesystem. There's no persistent content in a swap partition, so there's nothing to copy. All you need to do is identify a partition as a swap area within /etc/fstab, and the system will initialise it automatically at boot-time. What about the file system sizes. Will the restored hard drive have the same file system sizes as the source file system? No -- this is not necessary. So long as the target filesystem is sufficiently big to contain all of the contents of your dump, it should work fine. Is there some way to allocate larger file systems on the target without using sysinstall to prepare the target beforehand? Certainly. sysinstall(8) really isn't the right tool for this sort of disk operation once you've got beyond doing an initial installation. For the default combination of UFS+MBR look at the following man pages: * fdisk(8) -- create and manage PC slices on the drive * boot0cfg(8) -- install/configure boot managers (not generally needed) * bsdlabel(8) -- create BSD partition tables within a slice * newfs(8) -- write a filesystem onto a partition There are alternatives nowadays: gpart(8) effectively replaces fdisk and bsdlabel on systems using GPT or EFI or various other technologies. zfs(8) similarly replaces bsdlabel and newfs if you want to use that for managing your disks. For more information see: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-adding.html and succeeding chapters http://lists.freebsd.org/pipermail/freebsd-geom/2009-April/003440.html http://wiki.freebsd.org/ZFS Is there some command to display the file system allocation size? df(1) shows you the size of filesystems, bsdlabel(8) shows you the size of the underlying partitions. Normally the filesystem will completely fill the partition it is created in, but it is possible to increase the size of a partition without increasing the size of the filesystem. There's not much point in doing that, as it just wastes space: growfs(8) can expand a filesystem to match the enclosing partition. To see the size of partitions via bsdlabel(1): # bsdlabel da0s1 # /dev/da0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 67487663 41943044.2BSD 2048 16384 28552 b: 41943040 swap c: 716819670unused0 0 # raw part, don't edit 'size' is given here in units of 512byte sectors -- so the 'a' partiton is 32.2GiB. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuCT00ACgkQ8Mjk52CukIxiBACfWFxImCy9AamOcH3+pafroBCw 404Ani9lZiKoEQzMOx7iQAZycUIS9Wec =a97y -END PGP SIGNATURE- ___ 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
Re: Dump/restore to clone disk
On Mon, Feb 22, 2010 at 04:33:47PM +0800, Aiza wrote: I have seen this posted in the questions archives to be used to clone a active system hard drive to a USB cabled hard drive. Prepare the target #dd if=/dev/zero of=/dev/da0 count=2 # fdisk -BI /dev/da0 # bsdlabel -B -w da0s1 # newfs ?U /dev/da0s1a # / # newfs -U /dev/da0s1d # /var # newfs -U /dev/da0s1e # /tmp # newfs -U /dev/da0s1f # /usr Mount target file system ?a? # mount /dev/da0s1a /mnt # cd /mnt # dump -0Lauf - /dev/ad1s1a | restore -rf - # cd / # umount /mnt Mount target file system ?d? # mount /dev/da0s1d /mnt # cd /mnt # dump -0Lauf - /dev/ad1s1d | restore -rf - # cd / # umount /mnt Mount target file system ?e? # mount /dev/da0s1e /mnt # cd /mnt # dump -0Lauf - /dev/ad1s1e | restore -rf - # cd / # umount /mnt Mount target file system ?f? # mount /dev/da0s1f /mnt # cd /mnt # dump -0Lauf - /dev/ad1s1f | restore -rf - # cd / # umount /mnt I have questions about this method. Some of these questions sound like you have not been studying the documentation as you should. People on this list will quickly lose patience if you do not do your own homework before asking questions. There is nothing so futile as trying to trying to explain something to someone who has not done their homework. What happened to swap? The fstab will be showing it as the first file system on the hard drive slice. Is something missing here? Swap is never backed up. It makes no sense to back up swap. It is just scratch space used by the OS and completely irrelevant to any other system. Try looking in to the documentation. What about the file system sizes. Will the restored hard drive have the same file system sizes as the source file system? Read the documentation. They will have the same size as what you make them. Dump/restore do no create filesystems. They just back up and restore data withing filesystems. You create the partitions yourself. A filesystem is an identifiable - most likely a partition, could be a whole disk, that has had newfs run on it to create a filesystem structure and then mounted to some mount point you have created with mkdir. Is there some way to allocate larger file systems on the target without using sysinstall to prepare the target beforehand? Yes, you use fdisk and bsdlabel and finally newfs. But, you cannot do this willy-nilly on a disk that is already in use. This is well documented. Is there some command to display the file system allocation size? Oh come on. This is all over the documentation. Try: df -k There are lots of other ways you can look up too. jerry ___ 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
Re: Re: Dump/Restore?
On 14 Sep 2009 02:50, Chris Maness ch...@chrismaness.com wrote: On Sun, Sep 13, 2009 at 6:15 PM, Chris Maness ch...@chrismaness.com wrote: I level 0 dump of my server. I lost a file that I need back. Is it possible to use restore like tar and explode it into a directory instead of a pristine partition/mount? Or even better, is it possible to just extract a single file without exploding the whole tape dump? Sorry if the question seems stupid. Chris KQ6UP Sorry, I was reading the restore man from my mac, and it was not as clear. The restore does not seem to work from my mac (this is where my backup dumps reside as I have two massive HDs). I guess the mac restore would only work with HFS+ and not UFS. I guess the only way would be to move the massive dump file back over to the FreeBSD server. Thanks, Chris KQ6UP ___ Try using NFS or cat over ssh, something like $ ssh my_mac 'cat dumpfile' | restore -if - restore treats the file as a tape, so it doesn't pull any bytes until you ask it to. This should be the least network intensive way of doing it Good luck! Chris ___ 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
Re: Dump/Restore?
utis...@googlemail.com wrote: On 14 Sep 2009 02:50, Chris Maness ch...@chrismaness.com wrote: On Sun, Sep 13, 2009 at 6:15 PM, Chris Maness ch...@chrismaness.com wrote: I level 0 dump of my server. I lost a file that I need back. Is it possible to use restore like tar and explode it into a directory instead of a pristine partition/mount? Or even better, is it possible to just extract a single file without exploding the whole tape dump? Sorry if the question seems stupid. Chris KQ6UP Sorry, I was reading the restore man from my mac, and it was not as clear. The restore does not seem to work from my mac (this is where my backup dumps reside as I have two massive HDs). I guess the mac restore would only work with HFS+ and not UFS. I guess the only way would be to move the massive dump file back over to the FreeBSD server. Thanks, Chris KQ6UP ___ Try using NFS or cat over ssh, something like $ ssh my_mac 'cat dumpfile' | restore -if - restore treats the file as a tape, so it doesn't pull any bytes until you ask it to. This should be the least network intensive way of doing it Good luck! Chris Thanks, that looks like a pretty cool trick. Chris ___ 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
Re: Dump/Restore?
--- On Sun, 9/13/09, Chris Maness ch...@chrismaness.com wrote: From: Chris Maness ch...@chrismaness.com Subject: Re: Dump/Restore? To: freebsd-questions@freebsd.org Date: Sunday, September 13, 2009, 9:50 PM On Sun, Sep 13, 2009 at 6:15 PM, Chris Maness ch...@chrismaness.com wrote: I level 0 dump of my server. I lost a file that I need back. Is it possible to use restore like tar and explode it into a directory instead of a pristine partition/mount? Or even better, is it possible to just extract a single file without exploding the whole tape dump? Sorry if the question seems stupid. Chris KQ6UP Sorry, I was reading the restore man from my mac, and it was not as clear. The restore does not seem to work from my mac (this is where my backup dumps reside as I have two massive HDs). I guess the mac restore would only work with HFS+ and not UFS. I guess the only way would be to move the massive dump file back over to the FreeBSD server. If the dump was made on the mac, it's highly likely restore will need to be run from the mac. If it was made on freebsd, you'll likely need to run restore from freebsd. Assuming you run it from the appropriate place.. I don't have my Mac handy to check it's man pages, but in FreeBSD I believe in it that it would be #restore -i -f file or #restore -i device Then use 'ls' and 'cd' to find the file you want. In the restore : prompt you can add filename to add it to the restore list. Works with folders, too. extract to finally pull those out. YMMV, so read the docs. I would suspect the Mac has similar options, though can't confirm that at the moment. -Rich ___ 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
Re: Dump/Restore?
2009/9/14 Chris Maness ch...@chrismaness.com: utis...@googlemail.com wrote: On 14 Sep 2009 02:50, Chris Maness ch...@chrismaness.com wrote: On Sun, Sep 13, 2009 at 6:15 PM, Chris Maness ch...@chrismaness.com wrote: I level 0 dump of my server. I lost a file that I need back. Is it possible to use restore like tar and explode it into a directory instead of a pristine partition/mount? Or even better, is it possible to just extract a single file without exploding the whole tape dump? Sorry if the question seems stupid. Chris KQ6UP Sorry, I was reading the restore man from my mac, and it was not as clear. The restore does not seem to work from my mac (this is where my backup dumps reside as I have two massive HDs). I guess the mac restore would only work with HFS+ and not UFS. I guess the only way would be to move the massive dump file back over to the FreeBSD server. Thanks, Chris KQ6UP ___ Try using NFS or cat over ssh, something like $ ssh my_mac 'cat dumpfile' | restore -if - restore treats the file as a tape, so it doesn't pull any bytes until you ask it to. This should be the least network intensive way of doing it Good luck! Chris Thanks, that looks like a pretty cool trick. Chris Let me know how you get on with it, I gzip my dumps and can pipe together commands like that, so it should work! Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? ___ 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
Re: Dump/Restore?
On Sun, Sep 13, 2009 at 06:15:55PM -0700, Chris Maness wrote: I level 0 dump of my server. I lost a file that I need back. Is it possible to use restore like tar and explode it into a directory instead of a pristine partition/mount? Or even better, is it possible to just extract a single file without exploding the whole tape dump? Yes, it is easily done. Just use the 'interactive' option. First, be clear where you want the restores file[s] to go. The official way to do the interactive option is to cd in to the bottom level of the filesystem it is in and do it from there. Restore will then put the files in the directories where they were when the dump was made. So, if the file[s] were in /home/joes/files/ cd to /home and do the restore. It will take care of knowing about the joes and files subdirectories and build them if they are not there. But, really the general recommended way (and the way I do it) to do an interactive restore is to create a designated directory for it and cd in to that. It can be anywhere there is room for the files. So, for example, on some systems I have a large amount of extra space in a filesystem I mount as /work. Within that I create a directory I can recover (for lack of any more imaginative name). I cd to the /work/recover directory and do the interactive restore. eg do: cd /work/recover restore -if dump_device/file Then fish around amongst the directories. When you find the one[s] you need to restore, just do add filename You can keep going and add several files and directories. When you have all that you want/need, then type extract It will ask you what tape to start with. If the dump is a file or of there is only one tape or other device, type 1 If there are more than one tape, type in the number of the last tape. It will search backward through the list of tapes/devices until it finds the files. eg. if there are 7 tapes in the level 0 dump set, start with 7, then give it 6 and then 5, etc. It will quit asking when it finds the files. Finally, it will ask if you want to set ownership of . Say no unless you have a good reason for doing otherwise. Now, if you have used a separate directory as I suggest above, tell restore to quit and then look at the file[s] to make sure they are all right and then manually move then to whichever directory you want. You can then delete them from /work/recover but leave that directory around for when you need it again. This is good for any circumstance when you want to pull just one of a few files out of a dump (or a tar file). I do a similar thing when I untar stuff I have moved over. I make a /work/unroll directory and untar stuff in there and move whay I want to where I want it. This may seem to be an extra unnecessary step, but it cuts down on errors, in my handling directories and file locations. jerry Sorry if the question seems stupid. Chris KQ6UP ___ 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
Re: Dump/Restore?
On Sun, Sep 13, 2009 at 06:50:05PM -0700, Chris Maness wrote: On Sun, Sep 13, 2009 at 6:15 PM, Chris Maness ch...@chrismaness.com wrote: I level 0 dump of my server. I lost a file that I need back. Is it possible to use restore like tar and explode it into a directory instead of a pristine partition/mount? Or even better, is it possible to just extract a single file without exploding the whole tape dump? Sorry if the question seems stupid. Chris KQ6UP Sorry, I was reading the restore man from my mac, and it was not as clear. The restore does not seem to work from my mac (this is where my backup dumps reside as I have two massive HDs). I guess the mac restore would only work with HFS+ and not UFS. I guess the only way would be to move the massive dump file back over to the FreeBSD server. The dump is just a file and it should not matter where it is stored, but you will have to use some network access type thing such as an rsh or an NFS connection to read it. Another thing is that restores need to be done on the same OS that the dumps were written - regardless of where they are stored. dump/restore depends on knowing something about the underlying filesystem, so it is not transferable from one system to another and often even between one OS version to another, like tar tends to be.But, you can make the dump file move between where it is stored and a system that can restore from it using one of the network protocols. jerry Thanks, Chris KQ6UP ___ 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
Re: Dump/Restore?
On Mon, 14 Sep 2009 05:45:01 -0700 (PDT), Richard Mahlerwein mahle...@yahoo.com wrote: In the restore : prompt you can add filename to add it to the restore list. Works with folders, too. Excuse me, just a little terminology note: FreeBSD has directories, not folders. It doesn't have sheets of papers instead of files, too. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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
Re: Dump/Restore?
--- On Mon, 9/14/09, Polytropon free...@edvax.de wrote: From: Polytropon free...@edvax.de Subject: Re: Dump/Restore? To: mahle...@yahoo.com Cc: freebsd-questions@freebsd.org, Chris Maness ch...@chrismaness.com Date: Monday, September 14, 2009, 4:37 PM On Mon, 14 Sep 2009 05:45:01 -0700 (PDT), Richard Mahlerwein mahle...@yahoo.com wrote: In the restore : prompt you can add filename to add it to the restore list. Works with folders, too. Excuse me, just a little terminology note: FreeBSD has directories, not folders. It doesn't have sheets of papers instead of files, too. :-) Pie on my face. I work too much with multiple operating systems. *sigh* BTW, I also work and develop heavily with a (non BSD, non-open source) document imaging and workflow management software, so you probably will, at some point, see me confuse files and sheets of paper. I will not mind a gentle reminder just like the above when I do that . :) ___ 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
Re: Re: Dump/Restore?
On 14 Sep 2009 22:38, Richard Mahlerwein mahle...@yahoo.com wrote: --- On Mon, 9/14/09, Polytropon free...@edvax.de wrote: From: Polytropon free...@edvax.de Subject: Re: Dump/Restore? To: mahle...@yahoo.com Cc: freebsd-questions@freebsd.org, Chris Maness ch...@chrismaness.com Date: Monday, September 14, 2009, 4:37 PM On Mon, 14 Sep 2009 05:45:01 -0700 (PDT), Richard Mahlerwein mahle...@yahoo.com wrote: In the restore : prompt you can add to add it to the restore list. Works with folders, too. Excuse me, just a little terminology note: FreeBSD has directories, not folders. It doesn't have sheets of papers instead of files, too. :-) Pie on my face. I work too much with multiple operating systems. *sigh* BTW, I also work and develop heavily with a (non BSD, non-open source) document imaging and workflow management software, so you probably will, at some point, see me confuse files and sheets of paper. I will not mind a gentle reminder just like the above when I do that . :) Yeah, unfortunately I still think of 'folders', and am continually wrong-footed by the term 'directory' in a graphical environment, even after years of GNU and FreeBSD use. I have all sorts of strange habits that many will recognise as symptoms of multi-booting and running servers. There's no shame in that! Chris ___ 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
Re: Dump/Restore?
On Mon, 14 Sep 2009 22:02:49 +, utis...@googlemail.com wrote: Yeah, unfortunately I still think of 'folders', and am continually wrong-footed by the term 'directory' in a graphical environment, even after years of GNU and FreeBSD use. Just imagine if the Xerox Alto and its first GUI wouldn't have been invented in the US, but in Germany. Then we would refer to ring binders or lever arch folders, or ordners or actenordner (the german word is der Ordner or der Akten- ordner). Surely, this would be the default symbol: http://www.officexl.de/kopierpapier/images/ordner.jpg And all paper sizes defaults would refer to DIN A4 in the first place... what a beautiful imagination! :-) I have all sorts of strange habits that many will recognise as symptoms of multi-booting and running servers. There's no shame in that! Please don't get me wrong: There are correct places to use the term folder, e. g. when talking about mail folders (which can be represented as files (mbox) or directories with files (MH) on the disk level). But in the case discussed, directory is the correct term. There's no need to change proven terminology just because some company indoctrinates you to do so. :-) How important it is to use the correct terminology is when users start asking you questions about their modems (refers to PC), their TV and their brains (refers to speakers), or start complaining that the file system is too big (refers to the icon size in the file manager used), and want the same pictures at home as I have them at work (refers to the OS). To sum it up in quite your own words: I have all sorts of strange habits that many will recognise as symptoms of asperger's syndrome. There's no shame in that! :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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
Re: Re: Dump/Restore?
On 14 Sep 2009 23:14, Polytropon free...@edvax.de wrote: On Mon, 14 Sep 2009 22:02:49 +, utis...@googlemail.com wrote: Yeah, unfortunately I still think of 'folders', and am continually wrong-footed by the term 'directory' in a graphical environment, even after years of GNU and FreeBSD use. Just imagine if the Xerox Alto and its first GUI wouldn't have been invented in the US, but in Germany. Then we would refer to ring binders or lever arch folders, or ordners or actenordner (the german word is der Ordner or der Akten- ordner). Surely, this would be the default symbol: http://www.officexl.de/kopierpapier/images/ordner.jpg And all paper sizes defaults would refer to DIN A4 in the first place... what a beautiful imagination! :-) I have all sorts of strange habits that many will recognise as symptoms of multi-booting and running servers. There's no shame in that! Please don't get me wrong: There are correct places to use the term folder, eg when talking about mail folders (which can be represented as files (mbox) or directories with files (MH) on the disk level). But in the case discussed, directory is the correct term. There's no need to change proven terminology just because some company indoctrinates you to do so. :-) How important it is to use the correct terminology is when users start asking you questions about their modems (refers to PC), their TV and their brains (refers to speakers), or start complaining that the file system is too big (refers to the icon size in the file manager used), and want the same pictures at home as I have them at work (refers to the OS). To sum it up in quite your own words: I have all sorts of strange habits that many will recognise as symptoms of asperger's syndrome. There's no shame in that! :-) Certainly no shame in that, but also one should be corrected on errors of terminology. Sorry if I didn't make that clear (I didn't!). I merely meant to point out that the best of us make terminological errors, and that it's all part of our 'diversity'. However, you were still right to correct the term IMO. Chris ___ 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
Re: Dump/Restore?
On Sun, Sep 13, 2009 at 6:15 PM, Chris Maness ch...@chrismaness.com wrote: I level 0 dump of my server. I lost a file that I need back. Is it possible to use restore like tar and explode it into a directory instead of a pristine partition/mount? Or even better, is it possible to just extract a single file without exploding the whole tape dump? Sorry if the question seems stupid. Chris KQ6UP Sorry, I was reading the restore man from my mac, and it was not as clear. The restore does not seem to work from my mac (this is where my backup dumps reside as I have two massive HDs). I guess the mac restore would only work with HFS+ and not UFS. I guess the only way would be to move the massive dump file back over to the FreeBSD server. Thanks, Chris KQ6UP ___ 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
Re: Dump | Restore
target machine FreeBSD 6.2, target disk /dev/ad1s1a mounted on /mnt. Run dump -0aLf - / | ssh ip_address ''cd /mnt/ cat | restore - rf -'', dump/restore goes without any errors. 1 total nonsense: cat|restore instead of restore 2 probably nonsense: use rsh not ssh unless you really need encryption. Fstab fixed, but system failure to boot: BTX halted. bsdlabel -B ___ 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
Re: Dump | Restore
On Mon, Apr 20, 2009 at 1:31 PM, Daniels Vanags daniels.van...@smpbank.lvwrote: Unable to successfully dump | restore over ssh. Source machine FreeBSD 6.2, disk /dev/mirror/gm0s1a, target machine FreeBSD 6.2, target disk /dev/ad1s1a mounted on /mnt. Run dump -0aLf - / | ssh ip_address ''cd /mnt/ cat | restore - rf -'', dump/restore goes without any errors. dump L0af - / | ssh ip_addr '(cd /mnt; restore -rf -)' Fstab fixed, but system failure to boot: BTX halted. You could either do bdslabel -B or use sysinstall to do the same. Only you mount the slice to /, set bootable and softupdates, then chane the mount point to /mnt before you W to commit. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ___ 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
Re: Dump | Restore
On Mon, Apr 20, 2009 at 12:46:05PM +0200, Wojciech Puchar wrote: use rsh not ssh unless you really need encryption. Sure, you *could* do that, but be sure to encrypt *and* sign the backup stream beforehand, e.g. using openssl or gnupg... And even then, anyone sniffing that poorly encrypted (at layer 2) wireless LAN connection could still hijack the password, log into the backup host, and delete or corrupt the (encrypted) dump files. Perhaps it's better to use ssh anyway, even for encrypted and signed dump files. Creating and transfering a couple of key files to the clients and backup host and using ssh(1) is not hard. Really not. ;-) -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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
Re: Dump | Restore
On Monday 20 April 2009 14:59:55 cpghost wrote: On Mon, Apr 20, 2009 at 12:46:05PM +0200, Wojciech Puchar wrote: use rsh not ssh unless you really need encryption. Sure, you *could* do that, but be sure to encrypt *and* sign the backup stream beforehand, e.g. using openssl or gnupg... And even then, anyone sniffing that poorly encrypted (at layer 2) wireless LAN connection could still hijack the password, log into the backup host, and delete or corrupt the (encrypted) dump files. Perhaps it's better to use ssh anyway, even for encrypted and signed dump files. Creating and transfering a couple of key files to the clients and backup host and using ssh(1) is not hard. Really not. ;-) But doesn't use full network capacity. Closed circuit LAN's (yes, they still do exist) don't need ssh, but a level 0 dump of several TB of data does need full lan speed. -- Mel ___ 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
Re: Dump | Restore
Greetings, On Mon, Apr 20, 2009 at 4:31 AM, Daniels Vanags daniels.van...@smpbank.lvwrote: Unable to successfully dump | restore over ssh. Source machine FreeBSD 6.2, disk /dev/mirror/gm0s1a, target machine FreeBSD 6.2, target disk /dev/ad1s1a mounted on /mnt. Run dump -0aLf - / | ssh ip_address ''cd /mnt/ cat | restore - rf -'', dump/restore goes without any errors. Fstab fixed, but system failure to boot: BTX halted. Please help. I read up on what the BTX is. BooT eXtender -- url here http://www.freebsd.org/doc/en/books/arch-handbook/boot-boot2.html Long story short, BTX is what brings the PC BIOS/CMOS code execution from 16-bit real mode, to 32-bit protected mode. I've had repeated problems with name-brand PCs that result in a BTX halted. Whiteboxes/custom builds tend to work the best (and IMHO, last the longest). So asking the OP to flag slices or bsdlabels as bootable probably won't help, but I've been wrong before. :D ___ 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
Re: Dump | Restore
Tim Judd wrote: [snip] Long story short, BTX is what brings the PC BIOS/CMOS code execution from 16-bit real mode, to 32-bit protected mode. I've had repeated problems with name-brand PCs that result in a BTX halted. Whiteboxes/custom builds tend to work the best (and IMHO, last the longest). [snip] Often the so called name-brand PCs have quirky and inferior BIOS, as well as minor hardware glitches that sometimes get ironed out with subsequent chipset steppings. Since these are primarily manufactured and sold for the Windows crowd, Windows will mask many of these deficiencies. Have problem xyz-1001 with $mfr model blah and many times the answer is download $mfr driver revision so and so. This is where a known small hardware defect can be worked around in driver code to mask and hide the problem. This is Windows centric and if you're not using Windows then you're not supported. -Mike ___ 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
Re: Dump/Restore
Please Help! After dump-restore /dev, /proc, /usr/compat/linux/proc - is empty, system fealure to boot. Please guide me, how to dump/restore devfs. I am not sure about /usr/compat/linux/proc but /dev and /proc are created on the fly by the system: Lines are added into /dev for each new device that the system detects Lines are added into /proc for any new process started by the system There is not reason to dump or restore them. Bests. Olivier ___ 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
Re: Dump/Restore
On Thu, Apr 09, 2009 at 10:50:49AM +0300, Daniels Vanags wrote: Please Help! After dump-restore /dev, /proc, /usr/compat/linux/proc - is empty, system fealure to boot. Please guide me, how to dump/restore devfs. These are pseudo file systems, and are dynamically managed by the system. You aren't expected to back them up. If you're system failed to boot, how did you inspect the filesystem? -- Jonathan Chen j...@chen.org.nz -- Do not take life too seriously. You will never get out of it alive. ___ 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
Re: Dump/Restore
2009/4/9 Daniels Vanags daniels.van...@smpbank.lv: This is a source comp output, after dump/restore /dev is empty. I run freesbie on target machine. -Original Message- From: Chris Rees [mailto:utis...@googlemail.com] Sent: Thursday, April 09, 2009 11:56 AM To: Daniels Vanags Subject: Re: Dump/Restore 2009/4/9 Daniels Vanags daniels.van...@smpbank.lv: Please Help! After dump-restore /dev, /proc, /usr/compat/linux/proc - is empty, system fealure to boot. Please guide me, how to dump/restore devfs. df -h Filesystem Size Used Avail Capacity Mounted on /dev/mirror/gm0s1a 52G 37G 11G 78% / devfs 1.0K 1.0K 0B 100% /dev procfs 4.0K 4.0K 0B 100% /proc linprocfs 4.0K 4.0K 0B 100% /usr/compat/linux/proc But /proc, /dev, and /u/c/l/proc are full in that df output... What are you talking about? Try ls /dev, and post that. Pretty sure it should be normal. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? You need to check then, that /dev is mounted. # mount -t devfs devfs /dev Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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
Re: Dump/Restore
Please Help! After dump-restore /dev, /proc, /usr/compat/linux/proc - is empty, system fealure to boot. Please guide me, how to dump/restore it always should be - before mounted as pseudo-fs devfs. df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/mirror/gm0s1a 52G 37G 11G78%/ devfs 1.0K1.0K 0B 100%/dev procfs 4.0K4.0K 0B 100%/proc linprocfs4.0K4.0K 0B 100% /usr/compat/linux/proc Daniel Vanags Information Technology Department IT infrastructure system engineer JSC SMP Bank www.smpbank.lv Phone:+371 67019386 E-mail: daniels.van...@smpbank.lv mailto:daniels.van...@smpbank.lv ___ 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
Re: Dump/Restore
2009/4/9 Daniels Vanags daniels.van...@smpbank.lv: Please Help! After dump-restore /dev, /proc, /usr/compat/linux/proc - is empty, system fealure to boot. Please guide me, how to dump/restore devfs. df -h Filesystem Size Used Avail Capacity Mounted on /dev/mirror/gm0s1a 52G 37G 11G 78% / devfs 1.0K 1.0K 0B 100% /dev procfs 4.0K 4.0K 0B 100% /proc linprocfs 4.0K 4.0K 0B 100% /usr/compat/linux/proc But /proc, /dev, and /u/c/l/proc are full in that df output... What are you talking about? Try ls /dev, and post that. Pretty sure it should be normal. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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
Re: Dump/Restore
On Thu, Apr 09, 2009 at 10:50:49AM +0300, Daniels Vanags wrote: Please Help! After dump-restore /dev, /proc, /usr/compat/linux/proc - is empty, system fealure to boot. Please guide me, how to dump/restore devfs. You only dump(8) file systems. /dev /procfs /dev/mirror/..., etc are not filesystems. They are just directories.Don't dump them. /procfs is not even a real directory so it goes away and gets repopulated when the system boots again. They all need to live in the '/' filesystem and of what is dumpable, gets dumped when you dump / (the root filesystem). Unless I completely misunderstand what you are asking. jerry df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/mirror/gm0s1a 52G 37G 11G78%/ devfs 1.0K1.0K 0B 100%/dev procfs 4.0K4.0K 0B 100%/proc linprocfs4.0K4.0K 0B 100% /usr/compat/linux/proc Daniel Vanags Information Technology Department IT infrastructure system engineer JSC SMP Bank www.smpbank.lv Phone:+371 67019386 E-mail: daniels.van...@smpbank.lv mailto:daniels.van...@smpbank.lv ___ 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
Re: dump/restore problem
Ivan; when I started a migration to new HDD, according few how-tos, I got the following warning: # dump -0Lauf - /dev/ad0s1f | restore -rf - When debugging dump/restore problems, it is always best to dump to a file, and then restore from the file -- this allows you to see which of dump and restore is printing which message. I would guess that the Header with wrong dumpdate is this issue: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/118087 More surprising is: warning: ./.snap: File exists *expected next file 141455, got 146* DUMP: 2.86% done, finished in 3:35 at Thu Feb 5 01:44:32 2009 What exactly is your .snap entry? Is it actually a directory, or do you have a file called .snap that is getting in the way? The expected next file message indicates inode numbers out of sequence, which I would guess also come from restore -- if the warning about .snap comes from dump, then I would encourage you to make sure that dump cleanly creates its archive (to a file) before spelunking in the restore error messages. If you are short of space and are using several partitions on your new drive, just format the largest and place the output files there while you experiement. Andrew. ___ 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
Re: dump/restore don't work, handbook lies
dump -0af /mnt/d201gly-0.dump / [snip] restore -rf /mnt/restore/d201gly-0.dump it complains about '/' issues it complains about 'expecting YY got ZZ' I very rarely use dump/restore, but based on the man page I cannot see what's wrong other than the live fs issue already mentioned. Since no one has suggested the real problem, I would like to suggest that all those 'expecting ...' are also related to whatever errors were printed at the very beginning. So an actual dump of the exact output there would be useful. FWIW, for doing stuff like moving the root fs (which I have done more often than I would like) I recommend using tar -cp or rsync -a. I preserves everything I care about preserving, and it has well-known and well-tested semantics that I feel comfortable with. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgpR9EPx4KtGx.pgp Description: PGP signature
Re: dump/restore don't work, handbook lies
On Sunday 31 August 2008 18:03:53 Lloyd M Caldwell wrote: I needed to increase the size of my freebsd root (/). I booted, single user, attached a large usb freebsd formatted file system to receive the backup image. And you're sure that the large usb freebsd formatted file system is intact and that your dump is uncorrupted? -- Kirk Strauser ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
On Sun, Aug 31, 2008 at 05:03:53PM -0600, Lloyd M Caldwell wrote:
Hello,
this all on a 7.0 freebsd system.
There are a couple of things missing here. You may have done them
and just not mentioned them, but...
Dump/Restore do NOT work as indicated in the handbook (or man pages). It
would be better to remove information from the handbook rather then have
information that doesn't work.
I have used dump/restore hundreds or thousands of times, and
it works just as described although sometimes the media (tape
other disk, whatever) fails. But that is a separate issue.
Dump was still working.
I needed to increase the size of my freebsd root (/). I booted, single
user, attached a large usb freebsd formatted file system to receive the
backup image. I ran:
dump -0af /mnt/d201gly-0.dump /
Did you mount the large USB file system to /mnt?
mount /dev/-whatever_the_device_name /mnt
Otherwise it wrote the dump to /mnt on the old disk which you wiped.
it ran with no complaints and an image was left on the large usb file
system (d201gly-0.dump).
OK. Probably must have done the mount (maybe)
doing a df -k would have told you if /mnt had the USB mounted on it.
Did you really look at and verify that image?
Before rebooting and starting up the cdrom and fixit, do a
mkdir /junk
cd /junk
restore -ivf /mnt/d201gly-0.dump
and use it to look around and maybe even restore a file or two in
that scratch directory /junk (or any name you prefer) to make sure
it is really there.I always check dumps I must depend on because
tape media and occasionally others can be very unreliable - especially
DDS (DAT) and I have had to use a lot of that in the past. So, it
has become a regular habit. Checking it with one or two files is
no absolute guarantee that the whole dump is readable, but it sure
reveals the ones where I screwed up while making the dump and if the
whole media is bad.
I then booted off the livefs cdrom, went to the Fix-it from livefs.
I ran fdisk to setup a pc partition for freebsd owning the entire disk.
I presume you mean that you created a single FreeBSD slice on the disk.
Something like:
fdisk -BI da0
I ran disklabel to setup and define the swap and 'a' root partition.
I ran disklabel to install boot blocks.
That is backwards of what I usually do.
I usually do the bsdlabel that writes a new label and put
on a boot block first - as in:
bsdlabel -w -B da0s1
And then edit the label using bsdlabel to create the 'a' partition.
bsdlabel -e da0s1
And edit it (with vi or whatever editor you have specified, I use vi)) so
it has everything in an 'a' partition. That usually consists of
copying the 'c' line and changing the partition name ('c' to 'a') and
making it a '4.2BSD type instead of 'unused'
I ran newfs on this new 'a' partition.
This should be straightforward. Just:
newfs /dev/da0s1a
Note, of course, if the disk is SATA or IDE, it is ad0 instead of da0.
I ran fsck and mount on the new 'a' partition placing it at /mnt/root.
I turned on the large usb drive, fsck'ed it and mounted it on /mnt/restore.
I cd into /mnt/root and run:
restore -rf /mnt/restore/d201gly-0.dump
This looks all right if you got the mounts right.
it complains about '/' issues
it complains about 'expecting YY got ZZ'
This is common and normally inconsequential on a dump of a live
file system - and a dump of root from a running system, even in
single user is a live filesystem. It just means that something
changed from the time the dump directory was created and the
actual files were written out.
after an hour it completes and NO data file were restored. It did
recreate the directory structure but NOT A SINGLE FILE came back. I've
studied the man pages and have no clue how to rectify this. after
re-reading the handbook on backup basics, I'm sure that anyone using
them will loose everything. They are simply useless. take them offline.
This is not something a user can practice, as most (I) don't have
duplicate hardware of everything to try dump/restore methods and find
out they don't work.
what went wrong? how do i get my system back?
The most likely thing is getting the mounts wrong somewhere along
the line.
Try looking at that dump file on the USB unit using 'restore -vf'
Use the fixit and see what is really on it.Go beyond the
directory index and try to restore a file or two.
eg, boot the fixit, make some space to write - maybe using /tmp
cd in to that space
mount that USB device/filesystem
do restore -vf USB_FILE_SYSTEM (whatever the dive name is)
cd all over and pick a couple of small files to restore.
If stuff is there, you should be able to restore -rf if the
mounts are right.
If not, then you will need to use another backup - you do
make regular backups, of course.
[EMAIL PROTECTED]
I've been running freebsd since 2.1 and am
Re: dump/restore don't work, handbook lies
On Sun, Aug 31, 2008 at 06:53:36PM -0500, J.D. Bronson wrote: At 05:03 PM 8/31/2008 -0600, Lloyd M Caldwell wrote: Hello, this all on a 7.0 freebsd system. Dump/Restore do NOT work as indicated in the handbook (or man pages). It would be better to remove information from the handbook rather then have information that doesn't work. Are you trying to resize the same disc or migrate to a NEW disk? Migrating to a new (larger) disc is trivial, at least in my experience. (I have never tried to resize any partitions though on a same disc, since new hard drives are cheap enough) Here is what I do to migrate to a totally new disc: Shutdown and install 2nd DRIVE boot machine... run sysinstall on the 2nd DRIVE (slice/dice/and setup MBR) then I run a small script like this: (Some presumptions are made ahead of time here) #!/bin/sh newfs /dev/ad2s1a newfs /dev/ad2s1d newfs /dev/ad2s1e newfs /dev/ad2s1f newfs /dev/ad2s1g newfs /dev/ad2s1h sleep 4 tunefs -n enable /dev/ad2s1a tunefs -n enable /dev/ad2s1d tunefs -n enable /dev/ad2s1e tunefs -n enable /dev/ad2s1f tunefs -n enable /dev/ad2s1g tunefs -n enable /dev/ad2s1h sleep 4 mount /dev/ad2s1a /mnta mount /dev/ad2s1d /mntd mount /dev/ad2s1e /mnte mount /dev/ad2s1f /mntf mount /dev/ad2s1g /mntg mount /dev/ad2s1h /mnth dump -C 32 -0Lf - / | ( cd /mnta ; restore xf - ) dump -C 32 -0Lf - /usr | ( cd /mntd ; restore xf - ) dump -C 32 -0Lf - /var | ( cd /mnte ; restore xf - ) dump -C 32 -0Lf - /home | ( cd /mntf ; restore xf - ) dump -C 32 -0Lf - /staff | ( cd /mntg ; restore xf - ) dump -C 32 -0Lf - /users | ( cd /mnth ; restore xf - ) umount /mnt* Then shut down. Place the 2nd drive in the 1st slot and turn it back on. This is the right way, except you left out creating the /mnta.../mnth mount points - which you probably already have created, but are not there on a base system. jerry Maybe there is a better or simpler way, but I have been doing this for years and never had any issues. YMMV -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
On Mon, Sep 01, 2008 at 02:49:10AM +0100, RW wrote: On Sun, 31 Aug 2008 18:53:36 -0500 J.D. Bronson [EMAIL PROTECTED] wrote: dump -C 32 -0Lf - / | ( cd /mnta ; restore xf - ) One minor caveat: dumping a live filesystem require dump to take a snapshot, which in turn require soft-updates to be turned-on. The default in sysinstall is to enable it for everything but the root partition. It doesn't rewuire the snapshot. That is a feature that is helpful in not missing changes and needs the '-L' flag. But, it will dump just nicely without it and only be momentarily confused on restore if files are missing that show up in the dump directory and will not even know about files that are created after the dump directory was created. If you can tolerate that, then it is not a requirement. jerry ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
At 02:49 AM 9/1/2008 +0100, RW wrote: dump -C 32 -0Lf - / | ( cd /mnta ; restore xf - ) One minor caveat: dumping a live filesystem require dump to take a snapshot, which in turn require soft-updates to be turned-on. The default in sysinstall is to enable it for everything but the root partition. I always enable soft-updates on all partitions during install or anytime a drive is replaced :-) /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) /dev/ad0s1f on /home (ufs, local, soft-updates) /dev/ad0s1g on /staff (ufs, local, soft-updates) /dev/ad0s1h on /users (ufs, local, soft-updates) -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
On Mon, 1 Sep 2008 02:40:10 +0200 (CEST), Wojciech Puchar [EMAIL PROTECTED] wrote: Did you really run dump on a 'live' filesystem? The filesystem may be changing under the feet of dump, while it copies data. That is bound to cause trouble later on. but shouldn't make NO files restored, maybe few files that was changed while backing up. Yes that's true of course. I was merely replying to the obvious error. Failing to restore *any* files is a different issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
On Sun, 31 Aug 2008 17:03:53 -0600, Lloyd M Caldwell [EMAIL PROTECTED] wrote: Hello, this all on a 7.0 freebsd system. Dump/Restore do NOT work as indicated in the handbook (or man pages). It would be better to remove information from the handbook rather then have information that doesn't work. I needed to increase the size of my freebsd root (/). I booted, single user, attached a large usb freebsd formatted file system to receive the backup image. I ran: dump -0af /mnt/d201gly-0.dump / it ran with no complaints and an image was left on the large usb file system (d201gly-0.dump). Did you really run dump on a 'live' filesystem? The filesystem may be changing under the feet of dump, while it copies data. That is bound to cause trouble later on. I then booted off the livefs cdrom, went to the Fix-it from livefs. I ran fdisk to setup a pc partition for freebsd owning the entire disk. I ran disklabel to setup and define the swap and 'a' root partition. I ran disklabel to install boot blocks. I ran newfs on this new 'a' partition. I ran fsck and mount on the new 'a' partition placing it at /mnt/root. I turned on the large usb drive, fsck'ed it and mounted it on /mnt/restore. I cd into /mnt/root and run: restore -rf /mnt/restore/d201gly-0.dump it complains about '/' issues it complains about 'expecting YY got ZZ' The manpage of restore says: expected next file inumber, got inumber A file that was not listed in the directory showed up. This can occur when using a dump created on an active file system. If this is the error you are seeing, then this is the explanation of what went wrong too. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
At 05:03 PM 8/31/2008 -0600, Lloyd M Caldwell wrote: Hello, this all on a 7.0 freebsd system. Dump/Restore do NOT work as indicated in the handbook (or man pages). It would be better to remove information from the handbook rather then have information that doesn't work. Are you trying to resize the same disc or migrate to a NEW disk? Migrating to a new (larger) disc is trivial, at least in my experience. (I have never tried to resize any partitions though on a same disc, since new hard drives are cheap enough) Here is what I do to migrate to a totally new disc: Shutdown and install 2nd DRIVE boot machine... run sysinstall on the 2nd DRIVE (slice/dice/and setup MBR) then I run a small script like this: (Some presumptions are made ahead of time here) #!/bin/sh newfs /dev/ad2s1a newfs /dev/ad2s1d newfs /dev/ad2s1e newfs /dev/ad2s1f newfs /dev/ad2s1g newfs /dev/ad2s1h sleep 4 tunefs -n enable /dev/ad2s1a tunefs -n enable /dev/ad2s1d tunefs -n enable /dev/ad2s1e tunefs -n enable /dev/ad2s1f tunefs -n enable /dev/ad2s1g tunefs -n enable /dev/ad2s1h sleep 4 mount /dev/ad2s1a /mnta mount /dev/ad2s1d /mntd mount /dev/ad2s1e /mnte mount /dev/ad2s1f /mntf mount /dev/ad2s1g /mntg mount /dev/ad2s1h /mnth dump -C 32 -0Lf - / | ( cd /mnta ; restore xf - ) dump -C 32 -0Lf - /usr | ( cd /mntd ; restore xf - ) dump -C 32 -0Lf - /var | ( cd /mnte ; restore xf - ) dump -C 32 -0Lf - /home | ( cd /mntf ; restore xf - ) dump -C 32 -0Lf - /staff | ( cd /mntg ; restore xf - ) dump -C 32 -0Lf - /users | ( cd /mnth ; restore xf - ) umount /mnt* Then shut down. Place the 2nd drive in the 1st slot and turn it back on. Maybe there is a better or simpler way, but I have been doing this for years and never had any issues. YMMV -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
man pages and have no clue how to rectify this. after re-reading the handbook on backup basics, I'm sure that anyone using them will loose everything. They are simply useless. take them offline. i use restore regularly and it works. anyway - i do test my backups at least full backups. but never got that. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
Did you really run dump on a 'live' filesystem? The filesystem may be changing under the feet of dump, while it copies data. That is bound to cause trouble later on. but shouldn't make NO files restored, maybe few files that was changed while backing up. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
On Sun, 31 Aug 2008 18:53:36 -0500 J.D. Bronson [EMAIL PROTECTED] wrote: dump -C 32 -0Lf - / | ( cd /mnta ; restore xf - ) One minor caveat: dumping a live filesystem require dump to take a snapshot, which in turn require soft-updates to be turned-on. The default in sysinstall is to enable it for everything but the root partition. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore don't work, handbook lies
dump -C 32 -0Lf - / | ( cd /mnta ; restore xf - ) One minor caveat: dumping a live filesystem require dump to take a snapshot, which in turn require soft-updates to be turned-on. The default in sysinstall is to enable it for everything but the root again - it will still dump file, maybe with few files missing but not the whole dump ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore pain and suffering
Kevin Sanders wrote: I've been dumping and restoring a test system today, and I'm have very little success. Basically, I've been installing a base FreeBSD 7-RELEASE/i386 system, doing something like dump -0auL -f /mnt/test.root.dump, formating the drive and trying to restore -rf /mnt/test.root.dump. /mnt is a ufs formated usb drive. After the dump, I've even done a restore -rNf /mnt/test.root.dump just to make sure it doesn't complain out the dump file. I've read the handbook, found a few articles, googled all the errors. The header dumpdate thing is harmless, the expected next file is from it being a live system, but I'm not ending up with a system that is very usable. Doing a df, I see that sometimes I end up with a restored slice that is about the same size as my dump file, sometimes less than half. I know I'm not being very specific with what's not working, but is anyone really using dump/restore and having success with the restore part? I'm now full of doubt and worry that my real systems are not really backed up. I really wished this worked as easy as falling out of a boat and hitting water. Kevin I have used dump/restore to move systems onto other drives, sometimes even through an ssh connection. The only thing you have to remember is to: chmod 1777 /tmp ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore pain and suffering
On Mon, Apr 21, 2008 at 1:58 AM, Dominic Fandrey [EMAIL PROTECTED] wrote: Kevin Sanders wrote: I've been dumping and restoring a test system today, and I'm have very little success. Basically, I've been installing a base FreeBSD 7-RELEASE/i386 system, doing something like dump -0auL -f /mnt/test.root.dump, formating the drive and trying to restore -rf /mnt/test.root.dump. /mnt is a ufs formated usb drive. After the dump, I've even done a restore -rNf /mnt/test.root.dump just to make sure it doesn't complain out the dump file. I've read the handbook, found a few articles, googled all the errors. The header dumpdate thing is harmless, the expected next file is from it being a live system, but I'm not ending up with a system that is very usable. Doing a df, I see that sometimes I end up with a restored slice that is about the same size as my dump file, sometimes less than half. I know I'm not being very specific with what's not working, but is anyone really using dump/restore and having success with the restore part? I'm now full of doubt and worry that my real systems are not really backed up. I really wished this worked as easy as falling out of a boat and hitting water. Kevin I have used dump/restore to move systems onto other drives, sometimes even through an ssh connection. The only thing you have to remember is to: chmod 1777 /tmp I finally got a good restore. I meant to reply all to document my solution, but hit reply to Anders only I guess. I was booting off the Live CD and had to soft link /tmp to a drive with some free space. After that everything worked perfect. Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore pain and suffering
Kevin Sanders wrote: I've been dumping and restoring a test system today, and I'm have very little success. Basically, I've been installing a base FreeBSD 7-RELEASE/i386 system, doing something like dump -0auL -f /mnt/test.root.dump, formating the drive and trying to restore -rf /mnt/test.root.dump. /mnt is a ufs formated usb drive. After the dump, I've even done a restore -rNf /mnt/test.root.dump just to make sure it doesn't complain out the dump file. I've read the handbook, found a few articles, googled all the errors. The header dumpdate thing is harmless, the expected next file is from it being a live system, but I'm not ending up with a system that is very usable. Doing a df, I see that sometimes I end up with a restored slice that is about the same size as my dump file, sometimes less than half. I know I'm not being very specific with what's not working, but is anyone really using dump/restore and having success with the restore part? I'm now full of doubt and worry that my real systems are not really backed up. I really wished this worked as easy as falling out of a boat and hitting water. Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] i wrote this up: http://mikestammer.com/dokuwiki/bsd:dumprestore after setting up dump/restore for my backup solution. i used it to migrate from old hard drives to a RAID1 setup on a 3ware controller and everything went well. what errors are you seeing? Eric ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore pain and suffering
On Fri, Apr 11, 2008 at 6:29 PM, Eric [EMAIL PROTECTED] wrote: Kevin Sanders wrote: I've been dumping and restoring a test system today, and I'm have very little success. Basically, I've been installing a base FreeBSD 7-RELEASE/i386 system, doing something like dump -0auL -f /mnt/test.root.dump, formating the drive and trying to restore -rf /mnt/test.root.dump. /mnt is a ufs formated usb drive. After the dump, I've even done a restore -rNf /mnt/test.root.dump just to make sure it doesn't complain out the dump file. I've read the handbook, found a few articles, googled all the errors. The header dumpdate thing is harmless, the expected next file is from it being a live system, but I'm not ending up with a system that is very usable. Doing a df, I see that sometimes I end up with a restored slice that is about the same size as my dump file, sometimes less than half. I know I'm not being very specific with what's not working, but is anyone really using dump/restore and having success with the restore part? I'm now full of doubt and worry that my real systems are not really backed up. I really wished this worked as easy as falling out of a boat and hitting water. Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] i wrote this up: http://mikestammer.com/dokuwiki/bsd:dumprestore after setting up dump/restore for my backup solution. i used it to migrate from old hard drives to a RAID1 setup on a 3ware controller and everything went well. what errors are you seeing? Eric I don't have them handy, but I got the header dumpdate warning, which I guess is harmless. Then I would get hundreds of expected next file A found B error. Sometimes it would suddenly give me an abort [yn], if you hit n, then you just get another abort [yn] until you give up. I'll check out your link and give things a few more tries. I figured I must be doing something wrong since dump/restore is so highly recommended as the best choice. Thanks, Kevin. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore pain and suffering
On Fri, Apr 11, 2008 at 05:51:21PM -0700, Kevin Sanders wrote: I've been dumping and restoring a test system today, and I'm have very little success. Basically, I've been installing a base FreeBSD 7-RELEASE/i386 system, doing something like dump -0auL -f /mnt/test.root.dump, formating the drive and trying to restore -rf /mnt/test.root.dump. /mnt is a ufs formated usb drive. After the dump, I've even done a restore -rNf /mnt/test.root.dump just to make sure it doesn't complain out the dump file. I've read the handbook, found a few articles, googled all the errors. The header dumpdate thing is harmless, the expected next file is from it being a live system, but I'm not ending up with a system that is very usable. Doing a df, I see that sometimes I end up with a restored slice that is about the same size as my dump file, sometimes less than half. I know I'm not being very specific with what's not working, but is anyone really using dump/restore and having success with the restore part? I'm now full of doubt and worry that my real systems are not really backed up. I have used it many hundreds of times. The only problems have been with media failures. don't worry so much about the size. Check the files and see if they are good. Those sizes could be a lot of unused but allocated space in some circumstances and not in others. I really wished this worked as easy as falling out of a boat and hitting water. I've seen that fail before too. jerry Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore corrupted filesystems
Roland Smith wrote: Sorry if I wasn't clear. Most all of the data is readable and complete if I mount the filesystem read-only. It just panics the box when mounted read/write, and fsck can't fix the damage. That might be worth filing a PR for, especially the panics. Exactly what is damaged? Garbage in files? Wrong inode counts? I've had unclean filesystems because of panics, but nothing fsck_ffs couldn't fix. You might want to check the hardware too. Use smartmontools in case of (S)ATA drives. Smart says that the drives are fine, as does the manufacturer's disk fitness tools. All the files that are readable contain correct data, but the files that are corrupt are totally not readable, and cannot even be removed manually: --8-- rsync: readlink /raid/Backup/Pizzabox/2007-02-23/cyberleo/secondlife/linux/SecondLife_i686_1_13_2_15/skins/xui/es failed: Bad file descriptor (9) rsync: readlink /raid/Backup/Pizzabox/2007-02-23/cyberleo/secondlife/linux/SecondLife_i686_1_13_2_15/skins/xui/fr failed: Bad file descriptor (9) --8-- fsck_ufs dies after about 30 minutes of grinding with the following: --8-- ** Phase 2 - Check Pathnames DIRECTORY CORRUPTED I=93409222 OWNER=1002 MODE=40755 SIZE=512 MTIME=Feb 10 00:49 2007 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY SALVAGE? no MISSING '.' I=93409222 OWNER=1002 MODE=40755 SIZE=512 MTIME=Feb 10 00:49 2007 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS UNEXPECTED SOFT UPDATE INCONSISTENCY fsck_ufs: inoinfo: inumber -1170056596 out of range --8-- (full output is at http://home.cyberleo.net/cyberleo/workspace/Zip/Bugs/fbsd-20070320-corr/saba-fsck-raid.txt ) It's possible this might be a result of the odd interaction between geom_raid5 and UFS, as discovered in January ( http://www.nabble.com/geom_raid5-livelock--p8304142.html ), but I can't be sure. I've already chalked this up to just an unfortunate occurrence, as the circumstances that caused the corruption in the first place are likely either long gone or so obscure as to be nearly impossible for me to root out. Looking at /usr/src/sbin/dump/traverse.c, dump traverses the used inodes list and all directories. So if any of these is corrupt, your dump will be too. And if the contents of the inodes is corrupted, so will the dump. Thanks for this insight. I'll avoid dump/restore and just use manual copying for now. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net [EMAIL PROTECTED] Furry Peace! - http://www.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore corrupted filesystems
On Wed, Apr 18, 2007 at 04:09:22PM -0500, CyberLeo Kitsana wrote: Roland Smith wrote: Sorry if I wasn't clear. Most all of the data is readable and complete if I mount the filesystem read-only. It just panics the box when mounted read/write, and fsck can't fix the damage. That might be worth filing a PR for, especially the panics. Exactly what is damaged? Garbage in files? Wrong inode counts? I've had unclean filesystems because of panics, but nothing fsck_ffs couldn't fix. You might want to check the hardware too. Use smartmontools in case of (S)ATA drives. Smart says that the drives are fine, as does the manufacturer's disk fitness tools. All the files that are readable contain correct data, but the files that are corrupt are totally not readable, and cannot even be removed manually: Given that, I would try to make a dump(8) of it. If dump dies on a particular file, try to exclude that file from the dump either by rm-ing it or setting a nodump flag and try again. You may not actually be able to do the rm or nodump flag though if you cannot mount it with write permission. You might be able to force it mounted without doing the fsck in single user. Note that tar allows you to specify exclusions. I usually don't suggest using tar for mass moves because it has weaknesses with hard links and might also not transfer flags and permissions correctly. But, if tar is what it takes, then use it. Good luck, jerry --8-- rsync: readlink /raid/Backup/Pizzabox/2007-02-23/cyberleo/secondlife/linux/SecondLife_i686_1_13_2_15/skins/xui/es failed: Bad file descriptor (9) rsync: readlink /raid/Backup/Pizzabox/2007-02-23/cyberleo/secondlife/linux/SecondLife_i686_1_13_2_15/skins/xui/fr failed: Bad file descriptor (9) --8-- fsck_ufs dies after about 30 minutes of grinding with the following: --8-- ** Phase 2 - Check Pathnames DIRECTORY CORRUPTED I=93409222 OWNER=1002 MODE=40755 SIZE=512 MTIME=Feb 10 00:49 2007 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY SALVAGE? no MISSING '.' I=93409222 OWNER=1002 MODE=40755 SIZE=512 MTIME=Feb 10 00:49 2007 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS UNEXPECTED SOFT UPDATE INCONSISTENCY fsck_ufs: inoinfo: inumber -1170056596 out of range --8-- (full output is at http://home.cyberleo.net/cyberleo/workspace/Zip/Bugs/fbsd-20070320-corr/saba-fsck-raid.txt ) It's possible this might be a result of the odd interaction between geom_raid5 and UFS, as discovered in January ( http://www.nabble.com/geom_raid5-livelock--p8304142.html ), but I can't be sure. I've already chalked this up to just an unfortunate occurrence, as the circumstances that caused the corruption in the first place are likely either long gone or so obscure as to be nearly impossible for me to root out. Looking at /usr/src/sbin/dump/traverse.c, dump traverses the used inodes list and all directories. So if any of these is corrupt, your dump will be too. And if the contents of the inodes is corrupted, so will the dump. Thanks for this insight. I'll avoid dump/restore and just use manual copying for now. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net [EMAIL PROTECTED] Furry Peace! - http://www.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore corrupted filesystems
On Wed, Apr 18, 2007 at 04:09:22PM -0500, CyberLeo Kitsana wrote: Roland Smith wrote: Sorry if I wasn't clear. Most all of the data is readable and complete if I mount the filesystem read-only. It just panics the box when mounted read/write, and fsck can't fix the damage. That might be worth filing a PR for, especially the panics. Exactly what is damaged? Garbage in files? Wrong inode counts? I've had unclean filesystems because of panics, but nothing fsck_ffs couldn't fix. You might want to check the hardware too. Use smartmontools in case of (S)ATA drives. Smart says that the drives are fine, as does the manufacturer's disk fitness tools. That's at least some good news. --8-- rsync: readlink /raid/Backup/Pizzabox/2007-02-23/cyberleo/secondlife/linux/SecondLife_i686_1_13_2_15/skins/xui/es failed: Bad file descriptor (9) rsync: readlink /raid/Backup/Pizzabox/2007-02-23/cyberleo/secondlife/linux/SecondLife_i686_1_13_2_15/skins/xui/fr failed: Bad file descriptor (9) --8-- At least these files should be easy to replace, if necessary. fsck_ufs dies after about 30 minutes of grinding with the following: --8-- ** Phase 2 - Check Pathnames DIRECTORY CORRUPTED I=93409222 OWNER=1002 MODE=40755 SIZE=512 MTIME=Feb 10 00:49 2007 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY Did these problems start after a crash? SALVAGE? no What happens if you tell it to try and salvage? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp5z4guQPOE6.pgp Description: PGP signature
Re: dump/restore corrupted filesystems
Jerry McAllister wrote: Smart says that the drives are fine, as does the manufacturer's disk fitness tools. All the files that are readable contain correct data, but the files that are corrupt are totally not readable, and cannot even be removed manually: Given that, I would try to make a dump(8) of it. If dump dies on a particular file, try to exclude that file from the dump either by rm-ing it or setting a nodump flag and try again. You may not actually be able to do the rm or nodump flag though if you cannot mount it with write permission. You might be able to force it mounted without doing the fsck in single user. Note that tar allows you to specify exclusions. I usually don't suggest using tar for mass moves because it has weaknesses with hard links and might also not transfer flags and permissions correctly. But, if tar is what it takes, then use it. Force-mounting the filesystem works just fine. It's when I try to modify any munged file that it panics the box, with ufs_dirbad or somesuch. I have been using rsync to recover readable data, which handles hard-links, permissions, sparse files, and et cetera. I figure it's best, as that's what is used to drop the differential backups onto the box in the first place. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net [EMAIL PROTECTED] Furry Peace! - http://www.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore corrupted filesystems
Roland Smith wrote: --8-- ** Phase 2 - Check Pathnames DIRECTORY CORRUPTED I=93409222 OWNER=1002 MODE=40755 SIZE=512 MTIME=Feb 10 00:49 2007 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY Did these problems start after a crash? It's possible, but I cannot be absolutely certain. The machine is supposed to start itself up and shut itself down every day, running a total of about 4 hours a day, during the span when all other machines dump their backups. The only reason I noticed this failure was because it didn't power down one day. Investigation revealed that FSCK had failed and dropped to single user, with errors seen in the log. SALVAGE? no What happens if you tell it to try and salvage? This was a dry-run to get the error log. When I actually tried to repair the filesystem, fsck aborts shortly after, complaining that it cannot fix the filesystem, and cannot continue. Hence the current path of removing everything and re-newfs'ing. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net [EMAIL PROTECTED] Furry Peace! - http://www.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore corrupted filesystems
On Mon, Apr 16, 2007 at 09:11:48AM -0500, CyberLeo Kitsana wrote: I have a 1.2TB UFS2 filesystem with irrecoverable corruption. As such, I must move all 500GB or so of data off of it and re-newfs it. If the corruption is due to hardware failure, your data is probably lost. Ditto if the corruption is so bad that fsck_ffs can't handle it. You can e.g. tell fsck_ffs(8) to use a backup superblock, with the -b option. Does anybody know whether dump/restore can gracefully handle filesystem corruption, or will it happily back up and restore said damage to the pristine filesystem? Dump examines the filesystem to see which files need to be backed up. So dumping a corrupted FS will probably not produce the desired results. If it did, we wouldn't need backups. What you could do is use dd(1) with nc(1) to send a copy of the raw device data to another machine, and try if you can pry your data from that. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpyOmrbRZctd.pgp Description: PGP signature
Re: dump/restore corrupted filesystems
Roland Smith wrote: On Mon, Apr 16, 2007 at 09:11:48AM -0500, CyberLeo Kitsana wrote: I have a 1.2TB UFS2 filesystem with irrecoverable corruption. As such, I must move all 500GB or so of data off of it and re-newfs it. If the corruption is due to hardware failure, your data is probably lost. Sorry if I wasn't clear. Most all of the data is readable and complete if I mount the filesystem read-only. It just panics the box when mounted read/write, and fsck can't fix the damage. My question was more along the lines of whether or not dump/restore would see that those corrupted directory and file inodes were indeed corrupt and not bother attempting to back them up, or if it would happily back them up and restore them in their corrupted state to a new filesystem, thus trashing it. If it does, I can always use rsync. Dump examines the filesystem to see which files need to be backed up. So dumping a corrupted FS will probably not produce the desired results. If it did, we wouldn't need backups. Ironically, this is the machine that holds the backups. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net [EMAIL PROTECTED] Furry Peace! - http://www.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore corrupted filesystems
On Mon, Apr 16, 2007 at 11:14:35PM -0500, CyberLeo Kitsana wrote: Roland Smith wrote: On Mon, Apr 16, 2007 at 09:11:48AM -0500, CyberLeo Kitsana wrote: I have a 1.2TB UFS2 filesystem with irrecoverable corruption. As such, I must move all 500GB or so of data off of it and re-newfs it. If the corruption is due to hardware failure, your data is probably lost. Sorry if I wasn't clear. Most all of the data is readable and complete if I mount the filesystem read-only. It just panics the box when mounted read/write, and fsck can't fix the damage. That might be worth filing a PR for, especially the panics. Exactly what is damaged? Garbage in files? Wrong inode counts? I've had unclean filesystems because of panics, but nothing fsck_ffs couldn't fix. You might want to check the hardware too. Use smartmontools in case of (S)ATA drives. My question was more along the lines of whether or not dump/restore would see that those corrupted directory and file inodes were indeed corrupt and not bother attempting to back them up, or if it would happily back them up and restore them in their corrupted state to a new filesystem, thus trashing it. Looking at /usr/src/sbin/dump/traverse.c, dump traverses the used inodes list and all directories. So if any of these is corrupt, your dump will be too. And if the contents of the inodes is corrupted, so will the dump. Ironically, this is the machine that holds the backups. Oops. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpINMVo3zQiB.pgp Description: PGP signature
Re: dump/restore corrupted filesystems
On Mon, Apr 16, 2007 at 11:14:35PM -0500, CyberLeo Kitsana wrote: Roland Smith wrote: On Mon, Apr 16, 2007 at 09:11:48AM -0500, CyberLeo Kitsana wrote: I have a 1.2TB UFS2 filesystem with irrecoverable corruption. As such, I must move all 500GB or so of data off of it and re-newfs it. If the corruption is due to hardware failure, your data is probably lost. Sorry if I wasn't clear. Most all of the data is readable and complete if I mount the filesystem read-only. It just panics the box when mounted read/write, and fsck can't fix the damage. My question was more along the lines of whether or not dump/restore would see that those corrupted directory and file inodes were indeed corrupt and not bother attempting to back them up, or if it would happily back them up and restore them in their corrupted state to a new filesystem, thus trashing it. It depends on how they are corrupted. Really there are three situations. In the first, something happened to cause a problem with the filesystem structure - the block and their pointer chains/links. That would make fsck see errors and possibly refuse to complete. If that also affects the ability to read some actual file then neither dump/restore nor any other copy method will fix the situation. dump and other utilities will fail when reading the files and abort. You might be able to tinker around a little, figure out which actual files are affected and delete them or set dump not to read them and then copy all the rest. But, if you are unable to mount the filesystem as write, this might not work. If you are able to copy most, then those files would be uncorrupted in the new location. You would just have to figure out what to do about the files you could not read. Second would be a similar corruption to the filesystem structure blocks and links, but it happens to luckily not be in a place currently being used by any actual files. In this case, fsck would fail, but you could still read the files enough to copy them to some other space. In this case, the copy process, whether dump/restore or some other - dump/restore is probably best - would fix the problem nicely. The copy would be uncorrupted. The third situation would be where the data itself was miswritten - maybe by a routine that cobbled some computation or database utility or whatever. In this case, fsck would not see any problem with the filesystem. It would see that all the blocks and links were nicely accounted for. But the data would be bad and no amount of copying would fix it. If fact, dump or any other copy utility would read the files without errors just fine and dandy, because it would not know of the corruptions - so they would just follow it to the new copy. dump/restore won't make any difference to/fix any fsck type errors. It works above that level - on the files' data itself. fsck works below the file level, on blocks and file chain links, etc. If fsck finds an unfixable error, dump or any other utility will fail too if the error is in the area it is trying to read. When you have dump-ed, then if you need to restore in to a cleanly created new filesystem. Remember that newfs created a filesystem on a partition. Then the copy should not be corrupted from an fsck point of view. This is not because of anything that dump/restore would do, but because the newfs made a clean new system that fsck would be happy with. Now, if the data itself is corrupt - but readable, then dump will happily read the corrupt data and restore will happily write out what dump created. The data would be just as incorrect. But, again, that is not at the fsck level. It is at the file and directory level. fsck works on blocks and links and doesn't care anything about the actual data written in the blocks. It can find errors in blocks and links that are both in a real file chain or not currently part of any real file. Generally fsck can fix those, but there are some things that it cannot make a reasonable guess on. I hope this adds to the understanding rather than just confusing you more. Basically I am pointing out that there can be different types or places for corruption. No copying of files will fix a problem if the errors are within the structure or data of the file itself. But, since fsck doesn't look at the actual data, but rather on structural integrity in the filesystem - the entity within which the files reside, it is possible that it can find errors in places that are not part of an actual current file. If the latter is the case, then copying the files out of the corrupt filesystem in to a nice new one, freshly newfs-ed using dump/restore or some other method, can fix the problem. But, if there are errors in the data, then no method of copying the files will fix them. And, if the filesystem corruption makes it impossible to read some of the files, then no copying scheme will fix them. You might be able to tinker
Re: dump/restore question
Kimberly B wrote: If I have built a freebsd system to my liking and want to be able to reinstall fbsd to my pre-dump state (assuming the same slice configuration). I ran dump -L -0f - / dump -L -0f - /usr dump -L -0f - /var dump -L -0f - /tmp and save these files remotely. Could I then expect to reinstall fbsd and restore these dump files and have the same state of the system when I dumped? including all ports and all? kimberly Yes. Ymmv. Kevin Kinsey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DUMP + RESTORE
Grant Peel wrote: Hi all, I know that if I dump a filesystem (lets say a full dump), that everything says the restore filesystem needs to be at least as big as the one the dump was made from. But I dare ask this question anyway ... If I have a filesystem that is 10 GIG, but because I am only using 2 GIG of that can I restore it to a 3 GIg file system? I ask becuase somehow I have a 73 gig drive, but all my spare hard disks disks are only 36 Gig. You only need as much disk space where you are restoring as you actually used on the filesystem being dumped, so yes, if you really only used 2Gb then restoring to a 3Gb partition is fine. Just beware that a 3Gb partition before newfs will have less that 3Gb of usable space as some is taken up by filesystem overhead, and the 10% space is usually to be left free for speedier, less fragmented operation. But 2Gb of data will still fit comfortably. This is *one* of the reasons why dump is better than dd. dd just copies the whole slice, all 10Gb in this case, and then you'd be stuck :-) --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DUMP + RESTORE
On Wed, Nov 29, 2006 at 08:33:07AM -0500, Grant Peel wrote: Hi all, I know that if I dump a filesystem (lets say a full dump), that everything says the restore filesystem needs to be at least as big as the one the dump was made from. But I dare ask this question anyway ... If I have a filesystem that is 10 GIG, but because I am only using 2 GIG of that can I restore it to a 3 GIg file system? I ask becuase somehow I have a 73 gig drive, but all my spare hard disks disks are only 36 Gig. Should be no problem because dump/restore work on a file-by-file basis and not blocks or other hardware divisions. Since it will have to build directories and such, it might come out just a bit bigger than the actual dump file, but it should only use in the ballpark of the size of the dump file. Anyway, it does not depend on the size of the file system that was dumped, but rather on the amount of data that was dumped. jerry -GRant ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore question
Alexander Shikoff [EMAIL PROTECTED] writes: I maked two dumps of root filesystem with dump(8): - the first of level 0 (all files) - the second of level 3 on the next day after level 0 (all files new or modified since dump of level 0 or level 3) Now I'm trying to restore filesystem with restore(8): cat dump0 | (cd /mnt/ad0s1a restore -ruyf -) cat dump3 | (cd /mnt/ad0s1a restore -ruyf -) I'm getting next warning message: ./sbin/init: cannot create file: Operation not permitted ... And this warning appears for all files with `schg' flag. Makes sense; even if you aren't at a raised securelevel, I'm not sure you'd want restore to modify unchangeable files. But then again, one would need some way of handling your situation... In any case, make sure you do this without securelevel. Question: why the dump of level 3 contains files which were not modified since dump of level 0? It shouldn't (and doesn't for me). Maybe the inode was changed for some reason? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dump Restore to smaller partition
Hello, Does anyone know if the dump and restore method for moving a partition to a new disk requires the destination partition to be as big or bigger that the source? It will need to be big enough to contain all the data. It the old file system had a lot of empty (unused) space then the new one can be smaller by about the amount of space that was unused.. From my understanding, the whole partition, including blank space will be dumped and restored. If this is the case then the destination will need to be at least as big. Only the files (directories are also files) get dumped. It does not dump the filesystem as it was newfs-ed. Rather it makes a list of all the files directories by inode number and then dumps each along with all ownership, permission, flag and link information. My situation is as follows: I have a 30GB usr partition with about 10GB of data in it. I want to move this data (flags and all!) to a new 20GB usr partition. Will dump/restore do this? .. or what should i use? No problem. After making the new partition with disklabel and making a filesystem out of it with newfs. Presuming your old 30 GB filesystem is mounted as /fsa and the new 20 GB filesystem is mounted as /fsb, dump 0af /fsa/fsa.dump /fsa cd /fsb restore rf /fsa/fsa.dump should work just fine - although it makes me nervous to put the dump file in the same filesystem you are dumping. Since it makes the inode list before it starts dumping and creating the dump file, it should work. It just feels weird.So, if you have some other place to put a 10 GB dump file, then go ahead and use it instead. jerry Thanks! Gareth ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dump Restore to smaller partition
Jerry McAllister wrote: Hello, Does anyone know if the dump and restore method for moving a partition to a new disk requires the destination partition to be as big or bigger that the source? It will need to be big enough to contain all the data. It the old file system had a lot of empty (unused) space then the new one can be smaller by about the amount of space that was unused.. From my understanding, the whole partition, including blank space will be dumped and restored. If this is the case then the destination will need to be at least as big. Only the files (directories are also files) get dumped. It does not dump the filesystem as it was newfs-ed. Rather it makes a list of all the files directories by inode number and then dumps each along with all ownership, permission, flag and link information. My situation is as follows: I have a 30GB usr partition with about 10GB of data in it. I want to move this data (flags and all!) to a new 20GB usr partition. Will dump/restore do this? .. or what should i use? No problem. After making the new partition with disklabel and making a filesystem out of it with newfs. Presuming your old 30 GB filesystem is mounted as /fsa and the new 20 GB filesystem is mounted as /fsb, dump 0af /fsa/fsa.dump /fsa cd /fsb restore rf /fsa/fsa.dump should work just fine - although it makes me nervous to put the dump file in the same filesystem you are dumping. Since it makes the inode list before it starts dumping and creating the dump file, it should work. It just feels weird.So, if you have some other place to put a 10 GB dump file, then go ahead and use it instead. Just do it with pipes: dump -0af - /fsa | (cd /fsb; restore -rf -) Obviously /fsb must be mounted when you do this. If you feel paranoid and don't mind it taking longer dump -0af - /fsa | (cd /fsb; restore -ivf -) will do the restore in interactive mode, allowing you to quit if you make a mistake e.g. you see the cd failed. It would also let you select only a subset of files to restore. Specifying -b 64 to dump and restore might make it go quicker. And if this is a mounted UFS2 partition then dump should also take -L so it makes a checkpoint. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore over ssh question
From: Andy Firman [EMAIL PROTECTED] On Fri, May 06, 2005 at 04:28:40PM +0100, Xian wrote: To restore the filesystems: Boot from a rescue disk and create the partitions of on the disk. I've never smashed anything badly enough to need to work out how to do this. At least the partitions were still there. Well this is more complicated than it seems. First of all, using the fixit mode from 4.11-RELEASE-i386-disc2.iso and trying to use disklabel -e does not work. It gives this error: disklabel: /mnt2/stand/vi: No such file or directory It turns out vi is located at /mnt2/usr/bin/vi and one has to set EDITOR=/mnt2/usr/bin/vi for disklabel to work. Is that a bug? This also happens when I boot off disk1, enter fixit mode, and use the live filesystem with disk2. It is very easy to dump filesystems for backup, but it is not easy to restore filesystems. (I am trying to do this all over ssh...not tape) It is probably just better, easier, faster, to backup all your data and config files (rsync -e ssh -avp ...) and in case of disk failure, replace the disk, install fresh OS, then restore data and config files. What do you think? Why not just create a bootable disk *as* your backup. That's what I do. I run it once a week and then also backup every night to a disk based backup server. If my system disk fails, I just need to but off of my backup disk and then restore my nightly backups. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore over ssh question
On Fri, May 06, 2005 at 04:28:40PM +0100, Xian wrote: To restore the filesystems: Boot from a rescue disk and create the partitions of on the disk. I've never smashed anything badly enough to need to work out how to do this. At least the partitions were still there. Well this is more complicated than it seems. First of all, using the fixit mode from 4.11-RELEASE-i386-disc2.iso and trying to use disklabel -e does not work. It gives this error: disklabel: /mnt2/stand/vi: No such file or directory It turns out vi is located at /mnt2/usr/bin/vi and one has to set EDITOR=/mnt2/usr/bin/vi for disklabel to work. Is that a bug? This also happens when I boot off disk1, enter fixit mode, and use the live filesystem with disk2. It is very easy to dump filesystems for backup, but it is not easy to restore filesystems. (I am trying to do this all over ssh...not tape) It is probably just better, easier, faster, to backup all your data and config files (rsync -e ssh -avp ...) and in case of disk failure, replace the disk, install fresh OS, then restore data and config files. What do you think? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore over ssh question
On Friday 06 May 2005 15:34, Andy Firman wrote: I am following this guide: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/backup-basics.htm l and successfully dumped /, /usr, and /var over ssh to another box and called them root-back.gz, usr-back.gz, and var-back.gz. But I can't figure out the restore part. Let's say I replace the harddrive and need to restore the 3 dumped filesystems. How do I go about this for my 4.11 box? What I have done so far is: 1. Replace the hard drive 2. Minimal install of 4.11 so the drive is partitioned the same as before 3. Copied the 3 dumped/gzipped files over ssh to the system w/new drive 4. Then I booted into fixit mode, and am stuck here... How do I restore the 3 filesystems? Thanks, Andy ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] To restore the filesystems: Boot from a rescue disk and create the partitions of on the disk. I've never smashed anything badly enough to need to work out how to do this. At least the partitions were still there. Then newfs the partitions. Assuming you are putting back /tmp as well. You will need some temp space for restore to work. newfs -O2 -U /dev/ad0s1a newfs -O2 -U /dev/ad0s1d newfs -O2 -U /dev/ad0s1e newfs -O2 -U /dev/ad0s1f Then mount the filesystems. cd /mnt mkdir root var usr tmp mount /dev/ad0s1a root . . . mount /dev/ad0s1f usr Set the temp dir so restore can use all the temp space it wants setenv TMPDIR /mnt/tmp Then for each file system to be restored, cd into the right place, fetch the backup and restore it. cd /mnt/usr ssh BoxWithBackupsOn cat /path/to/backup | zcat | restore -rf - It would be a wise idea to test this on another box if you can because it is much nicer to attempt a restore knowing it has been done before. -- /Xian When the going gets tough, the tough take a coffee break unknown author ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump/restore indexing question
I have freebsd 4.10 on one of my production servers. I have been using the dump/restore combo to backup my drive, and I run a nightly dump -9 on the /home partition, and most of the dump -9s are dumped to a single tape since I don't have daily acs to swap the tapes more than once a month or so. I'm wondering if there is a utility that can index the dumps on a tape and list the time/date for each dump on the tape. I looked through the dump/restore/mt man pages, google'd, and looked though the ports without much luck. Well, you could do a 'restore -t' on the tape and pipe the output to a file. You would have to reposition the tape and then run the restore on it. Then you might have to sort it to suit yourself. Lack of a good index feature is a major deficiency of dump/restore from my point of view. Also, I hope you do an occasional dump 0 and not all just dump 9. jerry please CC this to my email, as I am not subscribed to the list anymore.. thanx in advance. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore
I'm looking for a way to split and concat dump files afterwards. This should possible, butg I've been see a solution for this until yet. split(1) and cat(1) perhaps? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore
On Mon, 12 Apr 2004 3:51 pm, Oliver Breuninger wrote: Hello, I'm looking for a way to split and concat dump files afterwards. This should possible, butg I've been see a solution for this until yet. regards You know that you can split dump files during the dump See man dump for the -B option. When you restore, restore will ask for the next volume if you have split it using -B. No need to join up again. Note dont use -B and -a together in a dump. -a will override -B What are you trying to do? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore
Hello Anubis, if I have dump-seesions from tape, and I want to write parts of it on DVDs. But I'm interested in to have each part as an correct dump file. regards anubis wrote: On Mon, 12 Apr 2004 3:51 pm, Oliver Breuninger wrote: Hello, I'm looking for a way to split and concat dump files afterwards. This should possible, butg I've been see a solution for this until yet. regards You know that you can split dump files during the dump See man dump for the -B option. When you restore, restore will ask for the next volume if you have split it using -B. No need to join up again. Note dont use -B and -a together in a dump. -a will override -B What are you trying to do? -- Oliver Breuninger X.509v3 CA Distribution Point http://ca.breuninger.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump restore
Oliver Breuninger wrote: I'm looking for a way to split and concat dump files afterwards. You can split a file into pieces using split -b, and put the pieces together again via cat. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dump/Restore to disk and tape
On Tue, 10 Dec 2002, Matthew D. Fuller wrote: On Mon, Dec 09, 2002 at 08:44:29PM -0800 I heard the voice of Oliver Crow, and lo! it spake thus: Of course this doesn't work because pax just creates the file 'dump.0.2002-10-10'. Is there some way to move a dump file to a set of tapes, without having to do the dump from the original filesystem? Have you tried symlinking dump.0.2002-10-10 to /dev/stdout, and then doing the | restore? Kinda a twisted way of doing it, but it may work. I tried that, but pax deletes the symlink and replaces it with the dump file. I also tried using the pax filename substitution facility, in the hope that that would persuade it to open the stdout device: % pax -r -f /dev/sa0 -s :.*:/dev/stdout: Don't try this at home! It deleted the /dev/stdout device entry. I think though I *have* found a solution. archive: % gtar cM dump.*.gz restore: % gtar xMO dump.0.2002-10-10.gz | zcat | restore -if - It's not ideal because it depends on a package that's not part of the standard FreeBSD install. It has to be gtar, to avoid the 2GB file size limitation of tar. I also think it won't recover if part of a tape is damaged, because it is storing compressed dump files. The ideal solution would be if dump had a feature to split a single existing dump file across multiple volumes. That way 'restore' would recover from read errors on the tape, and only the affected files would be lost, instead of the remainder of the archive. Oliver To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Dump/Restore to disk and tape
On Mon, Dec 09, 2002 at 08:44:29PM -0800 I heard the voice of Oliver Crow, and lo! it spake thus: Of course this doesn't work because pax just creates the file 'dump.0.2002-10-10'. Is there some way to move a dump file to a set of tapes, without having to do the dump from the original filesystem? Have you tried symlinking dump.0.2002-10-10 to /dev/stdout, and then doing the | restore? Kinda a twisted way of doing it, but it may work. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: dump/restore after filesystem layout changes
On 01-Dec-2002 [EMAIL PROTECTED] wrote: On Sun, Dec 01, 2002 at 10:40:58AM -0600, Conrad Sabatier wrote: Ok, now on to my question: I'd like to do a full backup on each of my filesystems, zap all the partitions and do a new fdisk/disklabel with more filesystems than I'm currently using. For example, create a new /home partition instead of using a symlink in / to /usr/home. I'm just wondering if this will present any problems when restoring from backups. I can't seem to glean this information from the man pages. Well it is going to work as long as the directory structure is not changed. But you will have to be extra carefull with your permissions when you backup/restore your files. (what are you going to use for backup? dump/restore?) Yes, I'll be restoring from the backups I just finished making yesterday using dump/restore (with an ATAPI CD burner, no less; still in awe of that!). :-) I'm thinking it *should* work OK, as long as, as you said, I'm careful with permissions, and make sure everything gets restored to the right locations under the new filesystem layout. I figure mtree(8) should be helpful with this. The main reason I want to do this, besides to reclaim some wasted space from having /, /var, and /tmp partitions that are larger than I really need, is to make incremental backups easier later on (again, now that I can finally use dump/restore with my __ATAPI__ CD burner). :-) I'll report back later as to how it all went. Thanks. Oh, and if anyone's curious as to how I got my CD burner to work with dump/restore, just let me know. It was really simple actually. I'm running 5.0-CURRENT, by the way, but you -stable users definitely have something to look forward to very soon (if it hasn't already been MFC'ed). :-) -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: dump/restore after filesystem layout changes
On 01-Dec-2002 Mark Stosberg wrote: On Sun, 1 Dec 2002, Conrad Sabatier wrote: Ok, now on to my question: I'd like to do a full backup on each of my filesystems, zap all the partitions and do a new fdisk/disklabel with more filesystems than I'm currently using. For example, create a new /home partition instead of using a symlink in / to /usr/home. I'm just wondering if this will present any problems when restoring from backups. I can't seem to glean this information from the man pages. Conrad, I did something similar once. I added a new disk that I wanted to replace my primary disk, but I wanted the partitioning a little different, like you did. It worked fine for me, copying over one partition at a time using cpio. I imagine then it will work in your case as well. If you are interested to know about the process I used, you could browse the disks section on freebsddiary.org which was the basic for my methodology. -mark http://mark.stosberg.com/ Cool. I'll definitely check it out. And if this all goes well, I'll maybe do a little write-up on the methodology involved that you could use on your site. Thanks. -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: dump/restore after filesystem layout changes
First of all, I just gotta say: ATAPICAM rocks!!! I can now use my ATAPI CD burner with dump/restore! Awesome!!! Ok, now on to my question: I'd like to do a full backup on each of my filesystems, zap all the partitions and do a new fdisk/disklabel with more filesystems than I'm currently using. For example, create a new /home partition instead of using a symlink in / to /usr/home. I'm just wondering if this will present any problems when restoring from backups. I can't seem to glean this information from the man pages. No problem. Just think out the order in which you do things - such as, build all your file systems first, make sure that you restore file systems that contain mountpoints before restoring the filesystems that use the mountpoints, etc. So, build your file systems including /, /usr, /var and /home, etc whatever. restore root (/) first touch up /etc/fstab if needed restore other file systems such as /usr restore stuff file systems mounted in /usr such as maybe /usr/local if you have one etc. jerry Thanks! -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: dump/restore after filesystem layout changes
On Sun, Dec 01, 2002 at 10:40:58AM -0600, Conrad Sabatier wrote: First of all, I just gotta say: ATAPICAM rocks!!! I can now use my ATAPI CD burner with dump/restore! Awesome!!! Ok, now on to my question: I'd like to do a full backup on each of my filesystems, zap all the partitions and do a new fdisk/disklabel with more filesystems than I'm currently using. For example, create a new /home partition instead of using a symlink in / to /usr/home. I'm just wondering if this will present any problems when restoring from backups. I can't seem to glean this information from the man pages. Well it is going to work as long as the directory structure is not changed. But you will have to be extra carefull with your permissions when you backup/restore your files. (what are you going to use for backup? dump/restore?) Thanks! -- Conrad Sabatier [EMAIL PROTECTED] Kyriakos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
