[GLLUG] Re: If RSYNC then how - also HDPARM?

Mike Neir lists at obscuredomainname.com
Mon Nov 5 10:40:54 EST 2007


Rsync will copy the files for you on an NTFS partition, but the thing it 
won't do is grab the permissions correctly. There's a lot of metadata in 
the NTFS filesystem that just doesn't exist on a *nix-style filesystem. 
In my opinion, trying to copy the Windows partition with rsync is a 
waste of time.

However, you can copy *nix filesystems with it quite easily. The flags I 
use for my typical rsyncs are "-avHlx" (yes, I know some of them are 
redundant... it's a habit). That will copy every attrbute of the 
file/directory when its copied, preserve both hard links and symlinks, 
and will only copy files/directories within that filesystem. The latter 
is useful for root partitions because it won't copy stuff out of 
partitions mounted on top of a subdirectory, such as /proc, /sys, or 
/home. You'll have to copy things on a partition by partition basis this 
way, but you'll know you're getting the best possible replication.

Hope this helps.

MN

Benjamin Cathey wrote:
> Okay - don't bother replying if all you have to suggest is to google it or 'there are plenty of howto's on the internet' -- I believe one of the main reasons I JOINED a lug was for the support locally and help if you need it.  At least that's how I see it . . . anyway . . . .
> 
> Please, as I expressed earlier - if you think rsync is a better option explain what flags, etc I would need to use.  The process if you will.  I know it would still need to be done from a boot disk.  I would have to partition the new drive.
> 
> Beyond that then what??  I really don't know here.  I have read about rsync but don't know all the flags, etc.  Also, does it support NTFS?  I mean, I know if I boot from a live cd, I can install NTFS-3G and mount the partitions as writable but beyond that what flags do I need?  and what about grub?
> 
> Also - as I side note, how about the fact that the new drive has a bigger cache on it?  Will linux automatically figure that out on it's own or do I need to use HD parm or some tool to tell it to use this extra space and 'optimize' the new hdd?
> 
> 
> Benjamin Cathey
> System Administrator
> Cathey Company
> 4917 Tranter St.
> Lansing, MI 48910 USA
> Phone:     517.393.4720
> Fax:       517.393.4225
> Toll Free: 800.333.1972
> "Service is Our Profession"
> 
> 
> ----- Original Message -----
> From: Richard Houser
> [mailto:rick at divinesymphony.net]
> To: Michael Watters
> [mailto:michael at watters.ws]
> Cc: Benjamin Cathey
> [mailto:benjamincathey at catheycompany.com], linux-user at egr.msu.edu
> Sent: Wed,
> 31 Oct 2007 20:20:39 -0400
> Subject: Re: [GLLUG] Dual-Boot Copy?
> 
> 
>> ->> -----BEGIN PGP SIGNED MESSAGE-----
>> ->> Hash: SHA1
>> ->> 
>> ->> > I'm a big fan of the KISS principle.  dd the drive to the new one and
>> ->> > resize the file systems, that's all you need to do.
>> ->> 
>> ->> As an image based copy, dd has the downside of transmitting all data,
>> ->> not just what's in the filesystem.  So, 1GB of data on a 500GB drive
>> ->> would be 500GB of data to copy via dd or 1GB of data to copy via rsync
>> ->> or tar.  Dd will also copy deleted data, so there might be security
>> ->> concerns as well.
>> ->> 
>> ->> In addition, dd will not allow you to change filesystem options like
>> ->> block size or special features like "tails", will keep any fragmentation
>> ->> or corruption, etc.  At a minimum, a filesystem based copy will detect
>> ->> these errors.  In the case you have a corrupt filesystem, making an
>> ->> image with dd before attempting repair can be the difference between a
>> ->> hosed partition or not.
>> ->> 
>> ->> The KISS method would actually favor creating the partition as desired
>> ->> and then copying the data to it.  Doing a larger copy then resize is a
>> ->> lot more complicated and resource intensive of an operation (not simple
>> ->> in any means).  In fact, back around 1999, that was just the way you did
>> ->> it, period (not all filesystems even supported resizing then).
>> ->> -----BEGIN PGP SIGNATURE-----
>> ->> Version: GnuPG v1.4.7 (GNU/Linux)
>> ->> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>> ->> 
>> ->> iD8DBQFHKRvVUMkt1ZRwL1MRAoe5AJ9DKss/7dX8d/DXlM2NZoy0/rh49gCgonM6
>> ->> DTrXVlnIFusRM7utUmOEUiw=
>> ->> =qmMA
>> ->> -----END PGP SIGNATURE-----
>> ->> 
> 
> **********************
> **  LEGAL DISCLAIMER   **
> **********************
> 
> This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this E-mail message from your computer. 
> 
> 
> _______________________________________________
> linux-user mailing list
> linux-user at egr.msu.edu
> http://mailman.egr.msu.edu/mailman/listinfo/linux-user
> 



More information about the linux-user mailing list