Hi, 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. thanks, -- 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
Hi, 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. thanks, -- 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 |
At 2004-12-02 02:40:53+0000, Ken Smith writes:> 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.There's no theoretical reason why the formats used by dump and restore shouldn't be forward and backward compatible, allowing an older restore (to an older filesystem type) to pick out the parts of the dump which make sense to it while ignoring parts which it doesn't understand. But they aren't, so it can't, so you're out of luck. [In theory, the filesystem could package itself, so an old restore binary running on a newer filesystem and given a newer dump would DTRT]. Bikeshed, bikeshed. Nick B
>There's no theoretical reason why the formats used by dump and >restore shouldn't be forward and backward compatible, allowing >an older restore (to an older filesystem type) to pick out the >parts of the dump which make sense to it while ignoring parts >which it doesn't understand. > >But they aren't, so it can't, so you're out of luck.This is a pretty interesting issue that I didn't realize. I've regularly restored dumps from a Solaris 8 machine to my FreeBSD 4.x machines. (We had data volumes on some old Solaris machines that I replaced with FreeBSD.) I guess FreeBSD and Solaris volumes are similar enough that the restore just worked. Jaime Bozza