[TriLUG] HDD Migration

[Marty Ferguson]

Oh ye of little faith.

cp's (1) -a option is a shorhand for -dpR
  - No *d*ereference of symlinks
  - *p*reserve file attributes if possible, and
  - *R*ecursive copy

Personally, I would have *ass*umed that -a does NOT override the default
SPARSE=auto, which implies preservation.  However, being everybit the
doubting thomas that you are, Weave, I went to the source, as it were.
http://ftp.gnu.org/gnu/fileutils/fileutils-4.1.tar.gz

Once again, GNU/Linux doesn't let me down, and performs as expected.

This assures me that cp's "-a" switch will copy sparse files unmolested.
The cp man page clarifies the conditions underwhich the sparse detection
and replacement is employed.   Interestingly, the code below implies
that since the "-a" switch does not CAUSE --SPARSE=auto, you
could opt to force (=always) or condense (=never), which would then, not
be a bona-fide archived copy.

If you are a belt-and-suspenders type, I suppose you could
# cp -a --SPARSE=auto $SRC $DEST

M

-----------------------
Here's the case statement for the the args.  You can see that
"a" does not override sparse.
----------------------

   while ((c = getopt_long (argc, argv, "abdfHilLprsuvxPRS:V:", 
long_opts, NULL))
	 != -1)
     {
       switch (c)
	{
	case 0:
	  break;

	case SPARSE_OPTION:
	  x.sparse_mode = XARGMATCH ("--sparse", optarg,
				     sparse_type_string, sparse_type);
	  break;

	case 'a':		/* Like -dpR. */
	  x.dereference = DEREF_NEVER;
	  x.preserve_owner_and_group = 1;
	  x.preserve_chmod_bits = 1;
	  x.preserve_timestamps = 1;
	  x.require_preserve = 1;
	  x.recursive = 1;
	  x.copy_as_regular = 0;
	  break;

	case 'V':  /* FIXME: this is deprecated.  Remove it in 2001.  */
	  error (0, 0,
		 _("warning: --version-control (-V) is obsolete;  support for\
  it\nwill be removed in some future release.  Use --backup=%s instead."
		   ), optarg);
	  /* Fall through.  */

	case 'b':

-------------------------------------------etc... etc... etc...


FireFox TIP O' THE DAY...
"/" temporarily brings up the find text widget... just like in less (1)!

Brian Weaver wrote:
> Keep in mind that any "copy" command you use is like to get rid of any
> "sparce" space in the files. If you use cp you might want to use the
> '--sparse' option. The rsync command also has some options for handing
> sparse files as well.
> 
> The dd command automatically handles sparse files because it simply
> copies the disk blocks, but as Shane pointed out you get all the
> fragmentation from the original disc too.
> 
> -Weave
> 
> Marty Ferguson [marty.ferguson at fergusonlx.nextelbroadband.net] wrote on Wed, Jan 05, 2005 at 04:33:32PM -0500:
> 
>>I still like Lance's solution, but for 1 alteration.
>>Being lazy, I just use
>># cp -a
>>to create a recursive archive copy of the orginial filesystem.
>>The good thing (compared to dd) is that, since no *nix has a
>>"defrag" you end up with one big whoppin chunk-o freespace using
>>cp -a.  dd will duplicate the fragmentation.  The contiguous-ness
>>probably goes the same for dump | restore into a brand-new mkfs'd
>>ext3, but I never compared.
>>
>>M
>>
>>Every time is too many I would care to mention...
>>or count on both hands.
>>
>>
>>Shane O'Donnell wrote:
>>
>>>Maybe it was because I missed the resize2fs step in the instructions, but I
>>>can't tell you how many times I've screwed myself using dd to copy drives
>>>over.
>>>
>>>Most new HDs come with a manufacturer's utility to do this and so far, it's
>>>worked for me every time.
>>>
>>>Keep in mind that:
>>>
>>>- "every time" is about 3-4 times 
>>>- "every time" includes IDE-only
>>>- "every time" usually involves only "home user" filesystems (e.g., fat,
>>>ext2, etc.)
>>>
>>>Shane "short on experience, long on advice" O.
>>>
>>>-----Original Message-----
>>>From: trilug-bounces at trilug.org [mailto:trilug-bounces at trilug.org] On 
>>>Behalf
>>>Of erik at underhanded.org
>>>Sent: Wednesday, January 05, 2005 3:23 PM
>>>To: Triangle Linux Users Group discussion list
>>>Subject: Re: [TriLUG] HDD Migration
>>>
>>>On Wed, Jan 05, 2005 at 02:19:00PM -0500, Jason Browne wrote:
>>>
>>>
>>>>I am trying to get some tips on migrating an install of Linux to another,
>>>>bigger HDD?  It is a straight 1 HDD to 1 HDD change...  I know I could use
>>>
>>>dd
>>>
>>>
>>>>, but I am trying to see if there is a better way.
>>>
>>>
>>>dd has worked fine for me many times, as long as you do resize2fs after
>>>the dump.
>>>
>>>If you recreate your top level directories (/tmp /bin /sbin etc), you
>>>can use 'cp -a' for most of them with good results.  Don't do it for
>>>lost+found, proc, dev, and sys(I think sys was special at least) though.
>>>
>>>For dev, just copy over MAKEDEV and any other non device files, along
>>>with all folders.  Then run MAKEDEV in the new /dev  This is all off the 
>>>top of my head, and probably quite a bit mroe work then a pure copy, but 
>>>it went fairly quickly in the few times I did it, and is a good way to 
>>>make sure everything copied over sanely.
>>>
>>>Or, there's ways of just using tar or cpio to do similiar in one step.
>>>
>>>But as I said, dd is easy, and hasn't screwed up in my experience.  Just
>>>make sure you shut down as many things as possible to keep your
>>>filesystem from being too much of a moving target. (log files
>>>especially)
>>>
>>
>>-- 
>>TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
>>TriLUG Organizational FAQ  : http://trilug.org/faq/
>>TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>>TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc
> 
>