On Tue, Apr 20, 2010 at 1:52 PM, Chris Dukes <pak...@pr.neotoma.org> wrote:
> > Just rethink your deployment strategy to not use 'dd'. > Even Windows cloning systems stopped trying to copy all bits > on the disk 6+ years ago. > 'dd' made some sense when the disk was mostly full and there was > a huge penalty to keep seeking between data and metadata. > 'dd' continues to make sense if you need to make a copy of > everything before attempting to recover data or metadata. > > <OSX idiocy> FYI, Mac OS X still benefits from 'dd' because of arguably idiotic Metadata. Trying to get files on an HFS+ volume to remain in tact while copying to/from a non-HFS+ environment is the stuff of nightmares. Even if you think you have properly retained all that annoying metadata, you'll still have to extract it and test it under whatever application it was which created that metadata. Often, just linefeed conversion (or lack thereof) will break OSX applications. </OSX idiocy> If you want to backup/restore data (for the purposes of imaging and deployment) you really should be using some kind of tar solution. rsync is nice, but tar works well with everything you'll have in sys and userland. Tar versions vary, but I disciplined myself from the start to understand the details of OpenBSD tar. I then use a -I /tmp/includes file for specialization. As long as you are creating and extracting your data sources from within OpenBSD (bsd.rd perhaps) tar should do the trick. Using the built-in 'make release' is even more fun.
