From owner-freebsd-questions@FreeBSD.ORG Tue May 25 03:15:04 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C68DD1065670 for ; Tue, 25 May 2010 03:15:04 +0000 (UTC) (envelope-from anti_spam256@yahoo.ca) Received: from n13.bullet.mail.ac4.yahoo.com (n13.bullet.mail.ac4.yahoo.com [74.6.228.93]) by mx1.freebsd.org (Postfix) with SMTP id 65CBF8FC0A for ; Tue, 25 May 2010 03:15:04 +0000 (UTC) Received: from [76.13.12.65] by n13.bullet.mail.ac4.yahoo.com with NNFMP; 25 May 2010 03:15:03 -0000 Received: from [76.13.10.175] by t6.bullet.mail.ac4.yahoo.com with NNFMP; 25 May 2010 03:15:03 -0000 Received: from [127.0.0.1] by omp116.mail.ac4.yahoo.com with NNFMP; 25 May 2010 03:15:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 689218.61055.bm@omp116.mail.ac4.yahoo.com Received: (qmail 59902 invoked by uid 60001); 25 May 2010 03:15:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1274757303; bh=NULFJpqaiMFWA2ijtFDEWf1p1Wg0eyd2AS/fniH1I00=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=QjmiA96iAYNq2/gZd6S6c1r83pqINHWxqf1ksfpFt+zlSQGOs5Gs6HKXNtGWDD5Th31vao5Epwg8U0cD3nuZmZz7h5ScOm96cWK22UUAuL+cKwTYAotz2bwJZVH8gcyltJxKprDXuvpwhNJzr+WyqDrWcjoFZwUULqN0/qkISfo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=5+ME6AoCG2HZfJO/Z1FrwGsKgmZX/OaCxbIK02SI39NbZ7SbXoNukCwLgrV//6qgsNclQY4L/jPtp3KywsYoDG7SnKnPc88uwcVgftr446UeF1TKjyVrYfJ/Olbd3gqER292kkIPITxXNnyxZasDOFfStRuNg9RFlI9AX6Rn3pk=; Message-ID: <332734.59134.qm@web65511.mail.ac4.yahoo.com> X-YMail-OSG: WPGfzqcVM1nYePxQfddC2AfM6CIGwjs7A6AtmbY.hNK613Y 7GamfA5YGFc_qwyXsXU3RNlHL0ZM7b_0mtVznk.kB841NaXpx4X672RPEZ41 LLic6jUwJqB3HfvlmUAV7MzX1BYmituYAFzBLvLwJRcXvOzLCfa9ZI2lylY7 pCjvccEKi.BvqsmLC2Yo3_tVQ7C0WmNJw2mKZbiZd.Pur3Ufpfog5K_sc1NF neXYjCGuFvDgQ3H9c0YWwUIW76TvaBnXzMnbQeJFYV0eHJ4Nn5meFjcvyqmD 4iAxqxnELmoZRhUCQC3_Cn.9mC43ovH36dMjq9xYZ4TEfWAbELfqOoPyu70O zC8tM Received: from [208.99.137.71] by web65511.mail.ac4.yahoo.com via HTTP; Mon, 24 May 2010 20:15:03 PDT X-Mailer: YahooMailClassic/11.0.8 YahooMailWebService/0.8.103.269680 Date: Mon, 24 May 2010 20:15:03 -0700 (PDT) From: James Phillips To: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: dump/restore (to DVD+R) test failure X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 03:15:05 -0000 Hello, It took reading the source code of a backup front-end to figure out that "incremental backups" are not the same thing as "multiple incremental backups on the same medium; spilling over to the next disk if necessary." As the handbook (section 18.12.1) says, dump has quirks due to its design dating back to 1975. Optical write-once media was punch tape or cards. Seeking to the middle of the media was time consuming, so daily tapes were simply written from the beginning, then rewound. So, knowing this, I decided to test a full dump and restore to DVD+R media, following the example in the dump(8) man page. I suspect that the example was written with DVD-R in mind, but according to wikipedia, http://en.wikipedia.org/wiki/DVD-R#Recordable_DVD_capacity_comparison the smaller DVD+R media can handle the example in dump(8) with 184 2048 byte blocks to spare (implying the example intended 3576 spare sectors). The package for the DVD media just says "4.7 GB" with only 2 significant digits. I used the following command for the dump: $/sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z -dvd-compat /dev/cd0=/dev/fd/0' /home Growisofs said 4700372992 bytes were written on the first disk (my notes don't record exactly which disk that was). That works out to 4590208kiB or 2295104 sectors. Edit: This matches the Wikipedia number; I assumed it to included zero padding I tried the restore on a fresh freeBSD 8.0 install with no user accounts created (and atapicam not yet enabled): dusty# cd /home #restore -r -P 'dd if=/dev/acd0 of=/dev/fd/1 bs=2048 count=2294920' warning: ./.snap: File exists expected next file 706561, got 4 unknown tape header type -365754194 abort? [yn] n resync restore, skipped 162 blocks expected next file 847904, got 0 acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x10 ascq=0x00 dd: /dev/acd0: Input/output error 2294208+0 records in 2294208+0 records out 4698537984 bytes transferred in 2781.175375 secs (1689407 bytes/sec) Mount tape volume 2 Enter ``none'' if there are no more tapes otherwise enter tape name (default: dd if=/dev/acd0 of=/dev/fd/1 bs=2048 count=2294920) unknown tape header type -54549208 abort? [yn] n resync restore, skipped 464 blocks expected next file 5040133, got 0 1201264+0 records in 1201264+0 records out 2460188672 bytes transferred in 1330.121340 secs (1849597 bytes/sec) dusty# The "unknown header type" errors appear to be unrelated to the major read error reported at the end to the first disk. I suspect those may be corruption caused by a buffer underrun or local vibration. Questions: 1. How do I determine which files (if any) are affected? is verbose mode required for that? 2. It appears the first disk lost 712 sectors of data (and a total of 896 sectors of capacity) with that read error. Should I just burn the disks 1024-4096 sectors short? 3. What is the best way to verify dumps at dump time? I still have the data on another disk. I can restore it with dd if need be. I verified the newfs command appears to create a ".snap" directory by default now. Regards, James Phillips