Re: disk recovery problem(s)
Thomas Exner thomas.ex...@uni-konstanz.de wrote: when running fsck the first error message is ROOT INODE UNALLOCATED ... Is there a chance to get the data back? Dunno about current versions, but IIRC some earlier versions of dump(8) could handle even a badly-corrupted FS. No harm in trying, since it will not try to write anything to the FS being dumped. Of course, you need to find a place to dump it to (and I would _not_ advise piping the output into restore(8) in this kind of situation -- save the dumpfile itself somewhere in case you find yourself needing to hack on restore(8) to extract files from it). ___ 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
disk recovery problem(s)
Dear all: I have a very similar problem as Roland Smith almost two years ago. My hard drive got corrupted (I do not really know why) and when running fsck the first error message is ROOT INODE UNALLOCATED (the full output of fsck is given below. I can then type y and it looks like that fsck is doing something. But in phase 3, when it tries to reconnect the inodes and put them in the lost+found directory, this directory cannot be created. If I mount the file system, there is still no root directory on the drive (no . and .. or anything else) and if I run fsck again, the exact same error massages occur again. If I only perform the ALLOCATE? and answer all the other questions with no, I get a . and .. in the root directory but nothing more. Running again fsck destroys everything again. Does anyone have an idea why fsck is not able to perform the recovery or why the changes are undone at one point? Is there a chance to get the data back? I do not know if it is important but the file system is on a raid5. Any help would be highly appreciated. Best, Thomas Full fsck output: nas1:/mnt# /sbin/fsck -t ufs -f /dev/raid5/nasraid1p1 ** /dev/raid5/nasraid1p1 ** Last Mounted on /mnt/nasraid1 ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ROOT INODE UNALLOCATED UNEXPECTED SOFT UPDATE INCONSISTENCY ALLOCATE? [yn] y BAD TYPE VALUE I=2 OWNER=root MODE=40755 SIZE=2048 MTIME=Nov 16 17:21 2010 DIR=/ UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? [yn] y BAD TYPE VALUE I=2 OWNER=root MODE=40755 SIZE=2048 MTIME=Nov 16 17:21 2010 DIR=/ UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? [yn] y BAD TYPE VALUE FOR '..' I=151745536 OWNER=root MODE=40755 SIZE=512 MTIME=Oct 19 17:19 2010 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? [yn] y BAD TYPE VALUE I=2 OWNER=root MODE=40755 SIZE=2048 MTIME=Nov 16 17:21 2010 DIR= UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? [yn] y BAD TYPE VALUE FOR '..' I=301465600 OWNER=root MODE=40755 SIZE=19968 MTIME=Nov 12 09:16 2010 DIR=? UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? [yn] y BAD TYPE VALUE I=2 OWNER=root MODE=40755 SIZE=2048 MTIME=Nov 16 17:21 2010 DIR= UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? [yn] y ** Phase 3 - Check Connectivity UNREF DIR I=151745536 OWNER=root MODE=40755 SIZE=512 MTIME=Oct 19 17:19 2010 RECONNECT? [yn] y NO lost+found DIRECTORY CREATE? [yn] y SORRY. CANNOT CREATE lost+found DIRECTORY UNEXPECTED SOFT UPDATE INCONSISTENCY UNREF DIR I=301465600 OWNER=root MODE=40755 SIZE=19968 MTIME=Nov 12 09:16 2010 RECONNECT? [yn] y NO lost+found DIRECTORY CREATE? [yn] y SORRY. CANNOT CREATE lost+found DIRECTORY UNEXPECTED SOFT UPDATE INCONSISTENCY UNREF DIR I=151745536 OWNER=root MODE=40755 SIZE=512 MTIME=Oct 19 17:19 2010 RECONNECT? [yn] y NO lost+found DIRECTORY CREATE? [yn] y SORRY. CANNOT CREATE lost+found DIRECTORY UNEXPECTED SOFT UPDATE INCONSISTENCY ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 35257960 files, 1247115068 used, 171932417 free (5559497 frags, 20796615 blocks, 0.4% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * -- Dr. Thomas E. Exner Juniorprofessur Theoretische Chemische Dynamik Fachbereich Chemie Universität Konstanz 78457 Konstanz Tel.: +49-(0)7531-882015 Fax: +49-(0)7531-883587 Email: thomas.ex...@uni-konstanz.de ___ 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: disk recovery problem II
huff@ newfs /dev/da3a /dev/da3a: 78167.2MB (160086512 sectors) block size 16384, fragment size 2048 using 426 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, ... 159949760 cg 0: bad magic number Bad drive, perhaps? What do sysutils/smartmontools say? ___ 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
disk recovery problem(s)
Had a power outage recently; when trying to fsck several external hard drives I'm getting unexpected errors. For example: huff@ fsck /dev/da3a ** /dev/da3a ** Last Mounted on /backup ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ROOT INODE UNALLOCATED ALLOCATE? [yn] a) what's probably happened? b) is there a way to recover the data? I can scrub the disk and restore, but would like to avoid that if at all possible. Robert Huff ___ 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: disk recovery problem(s)
On Fri, Feb 06, 2009 at 02:48:41PM -0500, Robert Huff wrote: Had a power outage recently; when trying to fsck several external hard drives I'm getting unexpected errors. For example: huff@ fsck /dev/da3a ** /dev/da3a ** Last Mounted on /backup ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ROOT INODE UNALLOCATED ALLOCATE? [yn] a) what's probably happened? Error messages are explained in Appendix A of /usr/share/doc/smm/03.fsck/paper.ascii.gz Unfortunately it says that this error should never happen. :-/ Is the drive connected by USB? Some USB disk interface chips are quite quirky. b) is there a way to recover the data? Answer y, and all directorys and files found in the root will appear in lost+found, unless the attempt to allocate the root inode fails.. 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) pgpBz44yeGud9.pgp Description: PGP signature
Re: disk recovery problem(s)
On Fri, 6 Feb 2009 14:48:41 -0500, Robert Huff roberth...@rcn.com wrote: Had a power outage recently; when trying to fsck several external hard drives I'm getting unexpected errors. For example: huff@ fsck /dev/da3a ** /dev/da3a ** Last Mounted on /backup ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ROOT INODE UNALLOCATED ALLOCATE? [yn] a) what's probably happened? b) is there a way to recover the data? I can scrub the disk and restore, but would like to avoid that if at all possible. I really hope you don't get into the trouble that I have (allthough you mentioned that you've got backups)... Your fsck output seems to indicate that fsck can handle the damage. You could now let it continue. If a parent inode has disappeared, its child inodes (orphaned ones) - or, to be correct, the files or directories they represent - get restored in the lost+found/ directory where their name (probably lost) gets replaced by the inode number. If it's a directory, it content will usually be present with the file names, only the topmost part of a hierarchy will be affected. -- Polytropon From 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: disk recovery problem(s)
Roland Smith writes: huff@ fsck /dev/da3a ** /dev/da3a ** Last Mounted on /backup ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ROOT INODE UNALLOCATED ALLOCATE? [yn] a) what's probably happened? Error messages are explained in Appendix A of /usr/share/doc/smm/03.fsck/paper.ascii.gz Unfortunately it says that this error should never happen. :-/ Answer y, and all directorys and files found in the root will appear in lost+found, unless the attempt to allocate the root inode fails.. Thank you. That worked ... sort of. Robert Huff ___ 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
disk recovery problem II
One of the disks mentioned in part one was not recoverable. So: newfs. However, something else is broken. Results of newfs is appended. What? Robert Huff huff@ newfs /dev/da3a /dev/da3a: 78167.2MB (160086512 sectors) block size 16384, fragment size 2048 using 426 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776, 12796128, 13172480, 13548832, 13925184, 14301536, 14677888, 15054240, 15430592, 15806944, 16183296, 16559648, 16936000, 17312352, 17688704, 18065056, 18441408, 18817760, 19194112, 19570464, 19946816, 20323168, 20699520, 21075872, 21452224, 21828576, 22204928, 22581280, 22957632, 2984, 23710336, 24086688, 24463040, 24839392, 25215744, 25592096, 25968448, 26344800, 26721152, 27097504, 27473856, 27850208, 28226560, 28602912, 28979264, 29355616, 29731968, 30108320, 30484672, 30861024, 31237376, 31613728, 31990080, 32366432, 32742784, 33119136, 33495488, 33871840, 34248192, 34624544, 35000896, 35377248, 35753600, 36129952, 36506304, 36882656, 37259008, 37635360, 38011712, 38388064, 38764416, 39140768, 39517120, 39893472, 40269824, 40646176, 41022528, 41398880, 41775232, 42151584, 42527936, 42904288, 43280640, 43656992, 44033344, 44409696, 44786048, 45162400, 45538752, 45915104, 46291456, 46667808, 47044160, 47420512, 47796864, 48173216, 48549568, 48925920, 49302272, 49678624, 50054976, 50431328, 50807680, 51184032, 51560384, 51936736, 52313088, 52689440, 53065792, 53442144, 53818496, 54194848, 54571200, 54947552, 55323904, 55700256, 56076608, 56452960, 56829312, 57205664, 57582016, 57958368, 58334720, 58711072, 59087424, 59463776, 59840128, 60216480, 60592832, 60969184, 61345536, 61721888, 62098240, 62474592, 62850944, 63227296, 63603648, 6398, 64356352, 64732704, 65109056, 65485408, 65861760, 66238112, 66614464, 66990816, 67367168, 67743520, 68119872, 68496224, 68872576, 69248928, 69625280, 70001632, 70377984, 70754336, 71130688, 71507040, 71883392, 72259744, 72636096, 73012448, 73388800, 73765152, 74141504, 74517856, 74894208, 75270560, 75646912, 76023264, 76399616, 76775968, 77152320, 77528672, 77905024, 78281376, 78657728, 79034080, 79410432, 79786784, 80163136, 80539488, 80915840, 81292192, 81668544, 82044896, 82421248, 82797600, 83173952, 83550304, 83926656, 84303008, 84679360, 85055712, 85432064, 85808416, 86184768, 86561120, 86937472, 87313824, 87690176, 88066528, 88442880, 88819232, 89195584, 89571936, 89948288, 90324640, 90700992, 91077344, 91453696, 91830048, 92206400, 92582752, 92959104, 93335456, 93711808, 94088160, 94464512, 94840864, 95217216, 95593568, 95969920, 96346272, 96722624, 97098976, 97475328, 97851680, 98228032, 98604384, 98980736, 99357088, 99733440, 100109792, 100486144, 100862496, 101238848, 101615200, 101991552, 102367904, 102744256, 103120608, 103496960, 103873312, 104249664, 104626016, 105002368, 105378720, 105755072, 106131424, 106507776, 106884128, 107260480, 107636832, 108013184, 108389536, 108765888, 109142240, 109518592, 109894944, 110271296, 110647648, 111024000, 111400352, 111776704, 112153056, 112529408, 112905760, 113282112, 113658464, 114034816, 114411168, 114787520, 115163872, 115540224, 115916576, 116292928, 116669280, 117045632, 117421984, 117798336, 118174688, 118551040, 118927392, 119303744, 119680096, 120056448, 120432800, 120809152, 121185504, 121561856, 121938208, 122314560, 122690912, 123067264, 123443616, 123819968, 124196320, 124572672, 124949024, 125325376, 125701728, 126078080, 126454432, 126830784, 127207136, 127583488, 127959840, 128336192, 128712544, 129088896, 129465248, 129841600, 130217952, 130594304, 130970656, 131347008, 131723360, 132099712, 132476064, 132852416, 133228768, 133605120, 133981472, 134357824, 134734176, 135110528, 135486880, 135863232, 136239584, 136615936, 136992288, 137368640, 137744992, 138121344, 138497696, 138874048, 139250400, 139626752, 140003104, 140379456, 140755808, 141132160, 141508512, 141884864, 142261216, 142637568, 143013920, 143390272, 143766624, 144142976, 144519328, 144895680, 145272032, 145648384, 146024736, 146401088, 146777440, 147153792, 147530144, 147906496, 148282848, 148659200, 149035552, 149411904, 149788256, 150164608, 150540960, 150917312, 151293664, 151670016, 152046368, 152422720, 152799072, 153175424, 153551776, 153928128, 154304480, 154680832, 155057184, 155433536, 155809888, 156186240, 156562592, 156938944, 157315296, 157691648, 158068000, 158444352, 158820704, 159197056, 159573408, 159949760 cg 0: bad magic number ___ freebsd-questions@freebsd.org
Re: disk recovery tools...
From professional experience as a data recovery technician, I can tell you that ufs2 drives are among the hardest to recover from after a there is a little change as UFS2 use lazy inode initialization. so possibly lots can be recovered. but i don't know any soft that does it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disk recovery tools...
moving disks from an old server to a new one I suffered from a moment of brain fade last night and newfs'ed a drive I shouldn't have. One of that new crop that is so large you won't have an adequate backup for it... :( no rescue. newfs overwrote inodes that contained your files metadata. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disk recovery tools...
with a subject this time... I've used /usr/ports/sysutils/testdisk to recover my BSD partitions, but it was just a HD failure/MBR nukage, no newfs was run on it - Try that. ]Peter[ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
disk recovery tools...
Guys, moving disks from an old server to a new one I suffered from a moment of brain fade last night and newfs'ed a drive I shouldn't have. One of that new crop that is so large you won't have an adequate backup for it... :( So, just wondering if there are any disk recovery tools that might be able to find whats left of the files or some portion thereof. My guess is that things like the indirect blocks live on in the data area and some portion of what was there might be recoverable to a greater or lesser degree... Thanks in advance, Enno. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disk recovery tools...
From professional experience as a data recovery technician, I can tell you that ufs2 drives are among the hardest to recover from after a format. So far the best applications that I have found for recovering data in a situation like this are testdisk and Easy Recovery Professional (by Kroll Ontrack). Obviously the ideal situation would be to get your data back in its original form, so I would try testdisk first. If that fails, however, you are going to have to use ERP (which cost money) to do a RAW recovery. Please note, however, that if you perform a RAW recovery,you will NOT recover the intact filestructure, but instead, a set of folders with your files, and the files will be renamed 'Fil001' followed by the extension. I hope this helps, Cypheros On 1/17/08, Enno Davids [EMAIL PROTECTED] wrote: Guys, moving disks from an old server to a new one I suffered from a moment of brain fade last night and newfs'ed a drive I shouldn't have. One of that new crop that is so large you won't have an adequate backup for it... :( So, just wondering if there are any disk recovery tools that might be able to find whats left of the files or some portion thereof. My guess is that things like the indirect blocks live on in the data area and some portion of what was there might be recoverable to a greater or lesser degree... Thanks in advance, Enno. ___ 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]
disk recovery
Hi, I have a personal server with 400Gb of hard disks in various shapes and sizes. I don't have enough money for redundant disks, and I would like to know what the most efficient way of making sure my data doesn't get lost, in case of a hard drive failure. The best would be for some sort of recovery if a disk goes south for the winter. On this note, what's the best way of recovering data when a disk does go bad. -- /~\ The ASCII ASCII stupid question, get a EBCDIC ANSI. \ / Ribbon Campaign John Oxley X Against HTMLhttp://oxo.rucus.net/ / \ Email! oxo at rucus.ru.ac.za Personally, I'd rather pay for my freedom than live in a bitmapped, pop-up-happy dungeon like NT. -- Thomas Scoville ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disk recovery
John Oxley wrote: Hi, I have a personal server with 400Gb of hard disks in various shapes and sizes. I don't have enough money for redundant disks, and I would like to know what the most efficient way of making sure my data doesn't get lost, in case of a hard drive failure. The best would be for some sort of recovery if a disk goes south for the winter. On this note, what's the best way of recovering data when a disk does go bad. You need to make backups to some other media, whether it be CD, or tape or a second set of disk drives. Doesn't sound easy. If you assume an average of 2:1 compression, you're still going to need 200G to back everything up. That'll take 50 DVDs ... If all of this data is important to you, then you need to come up with some cash. You might want to consider which of the data is _really_ important, and what you can survive losing and only back up the truely critical stuff. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: disk recovery
Even considering repairing an damaged HD as an method to replace backups is an stupid thought. People who do not backup critical data are fools. There is no price tag one can put on critical data. You find some way to backup to flat compressed file format and write to an removable HD or CDROM or some free web hosting site, BUT backup your data now. There is no substitute. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Oxley Sent: Monday, May 24, 2004 4:28 AM To: [EMAIL PROTECTED] Subject: disk recovery Hi, I have a personal server with 400Gb of hard disks in various shapes and sizes. I don't have enough money for redundant disks, and I would like to know what the most efficient way of making sure my data doesn't get lost, in case of a hard drive failure. The best would be for some sort of recovery if a disk goes south for the winter. On this note, what's the best way of recovering data when a disk does go bad. -- /~\ The ASCII ASCII stupid question, get a EBCDIC ANSI. \ / Ribbon Campaign John Oxley X Against HTMLhttp://oxo.rucus.net/ / \ Email! oxo at rucus.ru.ac.za Personally, I'd rather pay for my freedom than live in a bitmapped, pop-up-happy dungeon like NT. -- Thomas Scoville ___ [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: disk recovery
I used to think just like you. I thought I found the perfect balance between being on a budget and still having some kind of data security by using the Vinum software raid. So I stored the first 10 hours of video and 4k of still shots of my newly borned first child on the raid, and everything went well until one day when the kid crawled upfront the server and started to switch on switch of with a rate only a kid can achieve. One disk broke and I never managed to get it up again. So all memories from my sons first year where lost. Also I got no support whatsoever from this list when I asked for help to replace and recover the RAID system, so I was quite alone with vinum at that point... Today I have a hardware raid with a four disks volume and a fifth disk as spare. Some of the directories are each night copied to another machine for backup. Now and then (unfortunately mostly 'then') I burn newly taken pictures and films to DVD and put them in a box on my office (just in case of fire back home). If you have 400Gb of data I assume it's not material produced by yourself but perhaps downloaded films, music etc. If your'e on a budget, don't backup that. But do backup everything you've created yourself. So, don't repeat my misstake! //Joachim | I have a personal server with 400Gb of hard disks in various shapes and | sizes. I don't have enough money for redundant disks, and I would like | to know what the most efficient way of making sure my data doesn't get | lost, in case of a hard drive failure. The best would be for some sort | of recovery if a disk goes south for the winter. | | On this note, what's the best way of recovering data when a disk does go | bad. | I have a personal server with 400Gb of hard disks in various shapes and | sizes. I don't have enough money for redundant disks, and I would like | to know what the most efficient way of making sure my data doesn't get | lost, in case of a hard drive failure. The best would be for some sort | of recovery if a disk goes south for the winter. | | On this note, what's the best way of recovering data when a disk does go | bad. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disk recovery
Hi, Hi, I have a personal server with 400Gb of hard disks in various shapes and sizes. I don't have enough money for redundant disks, and I would like to know what the most efficient way of making sure my data doesn't get lost, in case of a hard drive failure. The best would be for some sort of recovery if a disk goes south for the winter. If that data is important, then it is worth the cost of backing up. On this note, what's the best way of recovering data when a disk does go bad. The only way is to restore it from a backup. You could try one of those emergency NSA type recovery services, but that would cost you far more than buying a backup system. So, whatever media you choose, shell it out for some backup capacity. In the short run, some additional disks might be the easiest and cheapest. Just add enough disk to hold everything and use dump(8) to a file on the extra disk to make the backup. Pull the disks and set them aside in a clean storage space. Use a different set of disk the next time and alternate/rotate them. Then if you need something or everything back, it is easy to get it using restore. You could create a mirroring system, but that is not quite a backup since it is left on the machine and is subject to the same environmental conditions that might cause the main disks to fail. In the longer run, it might actually still be cheaper to get a good tape system such as DLT.Then you can make a really good media rotation of maybe 5 sets, plus an occasional archive set. With that much data or more, don't bother with one of the cheapie tape systems. You will overload its duty cycle quickly and have to replace it too often. jerry -- /~\ The ASCII ASCII stupid question, get a EBCDIC ANSI. \ / Ribbon Campaign John Oxley X Against HTMLhttp://oxo.rucus.net/ / \ Email! oxo at rucus.ru.ac.za Personally, I'd rather pay for my freedom than live in a bitmapped, pop-up-happy dungeon like NT. -- Thomas Scoville ___ [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]
