From owner-freebsd-stable@FreeBSD.ORG Thu Dec 2 03:45:54 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0E0216A4CE for ; Thu, 2 Dec 2004 03:45:54 +0000 (GMT) Received: from titania.auscert.org.au (gw.auscert.org.au [203.5.112.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E838E43D49 for ; Thu, 2 Dec 2004 03:45:53 +0000 (GMT) (envelope-from joel@auscert.org.au) Received: from app.auscert.org.au (app [10.0.1.192])iB23fT6t064725; Thu, 2 Dec 2004 13:41:29 +1000 (EST) Received: from app.auscert.org.au (localhost [127.0.0.1]) by app.auscert.org.au (8.12.10/8.12.10) with ESMTP id iB23jkiP069095; Thu, 2 Dec 2004 13:45:47 +1000 (EST) Message-Id: <200412020345.iB23jkiP069095@app.auscert.org.au> To: freebsd-stable@freebsd.org In-Reply-To: Your message of "Wed, 01 Dec 2004 21:40:53 EST." <20041202024052.GA11786@electra.cse.Buffalo.EDU> Date: Thu, 02 Dec 2004 13:45:46 +1000 From: Joel Hatton cc: Ken Smith Subject: Re: 4.x can't read 5.x dump? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2004 03:45:54 -0000 Thanks Ken (and thanks to Paul, who replied with similar info), I can appreciate this - I shouldn't have been, but I guess I was just caught out by the change in the filesystem type and didn't realise that dump depended so heavily on it. I can work around, so all is well. Sorry about the double posting btw, I didn't expect my first one to make it to the list. cheers, -- Joel Hatton -- Security Analyst | Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland | WWW: www.auscert.org.au Qld 4072 Australia | Email: auscert@auscert.org.au > On Thu, Dec 02, 2004 at 10:48:43AM +1000, Joel Hatton wrote: > > > I'm backing up a 5.x machine at the moment with this command: > > > > dump -0Lau -b128 -f - /var | gzip -2 | ssh FreeBSD4 dd of=aacd0s1f.gz > > > > After the dump finishes, I try to read the file on the 4.x destination: > > > > # gzip -dc aacd0s1a.gz | restore -ivf - > > Verify tape and initialize maps > > Tape is not a dump tape > > > > I can scp the file back to the 5.x machine and it loads just fine, so what > > gives? This type of failure is somewhat scary for me right now, given that > > I may have to restore files to another destination that may not be 5.x > > based. > > This is, unfortunately, something that you should not expect to work > for any *nix variant. The dump mechanism of creating backups creates > output that has "intimate knowledge" of the filesystem so that it can > recreate that filesystem exactly as it exists on the disk. As the > filesystem itself evolves (has features added to it) the dump programs > need to have their data structures change to accomodate the extra > information that is now needed. For example if in 4.X there were no > ACLs but 5.X added ACLs then the dump program's data structures would > need to be changed so it had the ability to store the ACL information > in the output, and the restore program would need to be modified to > look for that and do the right thing if it finds ACL information. > > If there had been no filesystem changes between 4.X and 5.X then > there would not be any need to change dump, and what you are trying > to do would work. But there were filesystem changes between 4.X and > 5.X, so dump was changed, and now there is extra stuff in the dump > images that the 4.X version of restore doesn't understand. This same > general principle holds for all OS's, not just FreeBSD. > > If you need to be able to "restore" stuff from a 5.X machine on a > variety of different platforms (4.X, or some other *nix) then don't > use dump to create the images, use something like Gnu tar which can > be made to understand the concept of incremental backups. You do > however run the risk of not being able to do a "perfect" restore of > a filesystem if you use some of the more advanced filesystem features > like immutable files or ACLs - the tar mechanisms of doing backups > may not be able to record that extra information. > > -- > Ken Smith > - From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel |