From owner-freebsd-bugs@FreeBSD.ORG Tue Aug 12 20:00:28 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC49B249 for ; Tue, 12 Aug 2014 20:00:28 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3E5A288E for ; Tue, 12 Aug 2014 20:00:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7CK0S6O076958 for ; Tue, 12 Aug 2014 20:00:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 192622] New: restore corrupting filesystem when using dump levels Date: Tue, 12 Aug 2014 20:00:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ahamiltonwright@mta.ca X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 20:00:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192622 Bug ID: 192622 Summary: restore corrupting filesystem when using dump levels Product: Base System Version: 10.0-RELEASE Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: ahamiltonwright@mta.ca I was attempting to restore my /usr partition today, and have encountered some rather terrifying issues using restore. Some background ... I have used dump/restore for several years, very happily, to maintain backups on my machine. I have a level 0 dump of each file system, and then a cron-based script that does higher level dumps on a regular basis. I therefore have dumps at the following levels for this filesystem at the moment: 0, 2, 3, 5 These were created using snapshots, so the level 0 was created via dump 0uLCf 32 - /usr and higher level dumps were created similarly. My uname info is: FreeBSD qemg.org 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8 06:37:44 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I wanted to restore the /usr partition to the state it was in at the last (level 5) backup. My expected steps to achieve this are: o go to single user (I did this through a full reboot) o create a replacement filesystem on the drive (these options were constructed by running "dumpfs -m" on the filesystem that was present and being replaced: newfs -O 2 -U -a 4 -b 32768 -d 32768 -e 4096 -f 4096 \ -g 16384 -h 64 -i 8192 -k 0 -m 8 -o time \ -s 415236096 /dev/ada0e o mount the drive as /usr, and change directory to the mount point o restore the level 0 dump (that was created a month ago -- July 11, 2014, using this same kernel, but probably an earlier patch level) restore ruf /backup/dumps/current/usr.dump * this is the first sign of trouble, as restore output the warning expected next file 19266003, got 19100935 o restore the level 2 dump (created August 1, 2014) restore ruf /backup/dumps/current/l1d0/l2d0/usr.dump * this failed, indicating that the restore was corrupt output of restore is as follows: ./src: (inode 10032000) not found on tape ./ports: (inode 14205312) not found on tape bad entry: removeleaf: not a leaf name: ./local/share/licenses/openldap-client-2.4.39 parent name ./local/share/licenses sibling name: ./local/share/licenses/RSTTMP03130448 next entry name: ./local/share/licenses/openldap-client-2.4.39/OPENLDAP entry type: NODE inode number: 3613621 flags: NIL abort? [yn] y dump core? [yn] n Frankly, this terrifies me. If dump and restore cannot be trusted as a robust backup solution, I don't know where to turn to. If it would help to send along the actual dump files, I am happy to do this (they simply contain the /usr partition data), but as they are many Gb in size, I will wait until requested. I will note that on the questions mailing list, someone brought up the 2011 bug regarding soft updates and snapshots, which may be a contributing factor here. The referenced bug is this one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160662 I will certainly switch my dump script to ensure that soft updates are turned off for the duration of the dump process. -- You are receiving this mail because: You are the assignee for the bug.