Date: Thu, 13 Jan 2011 09:58:15 +0200 From: "Luchesar V. ILIEV" <luchesar.iliev@gmail.com> To: Pete French <petefrench@ticketswitch.com> Cc: zeus@ibs.dn.ua, freebsd-geom@freebsd.org Subject: Re: "secondary GPT table is corrupt or invalid" issue again Message-ID: <4D2EB097.3030202@gmail.com> In-Reply-To: <E1Pceom-000C3D-Qt@dilbert.ticketswitch.com> References: <E1Pceom-000C3D-Qt@dilbert.ticketswitch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/11/2011 16:03, Pete French wrote: >> 8. rsync -avH /src/ /dst/ >> but i have to admit thet rsync was much slower than tar ... it was >> about 8-9 hours for 750G of data to copy > > Use /usr/ports/sysutils/cpdup instead - faster, and designed to make > exact copiues which rsync doesn't to the bets of my knoedge. It's > what I always use form copying running installations around, and works > flawlessly. If you have both drives mounted then it's definitely > the way to go. Hi Pete, Thanks for the hint on cpdup. It does seem like an interesting alternative, though it usually gives me the shivers when I hear anything even remotely resembling cpio. ;) I don't know what you mean by rsync not making exact copies. With patches, rsync could even preserve atimes and file flags. If you mean "copying from running systems", as I see cpdump claims to be able to copy devices as well (I suppose this should really mean device nodes), I'm not quite sure if that's really a good practice anyway (and I really can't think of many reasons to copy or backup device nodes). BTW, rsync is also capable of delta-encoding, which could in theory provide significant savings in terms of transferred data, though I suppose its practical effectiveness depends heavily on the exact type of data that is being copied or backed up. More info on the subject: http://en.wikipedia.org/wiki/Rsync Cheers, Luchesar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D2EB097.3030202>