<p>Replacing the booted os with an archived copy may also replace /proc. Though there may be a way to avoid that.</p>
<p><a href="http://sourcefreedom.com">http://sourcefreedom.com</a></p>
<div class="gmail_quote">On Mar 4, 2012 1:48 PM, "Courtney Thomas" <<a href="mailto:courtneycthomas@bellsouth.net">courtneycthomas@bellsouth.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/03/12 15:03, Wolf Halton wrote:<br>
> On Fri, Mar 2, 2012 at 2:23 PM, Ed Cashin<<a href="mailto:ecashin@noserose.net">ecashin@noserose.net</a>> wrote:<br>
>> I've done that, but more often, "NEWdrive" is bigger than "HD1" and<br>
>> "HD2". I don't have the exact commands handy, but I can describe<br>
>> them, and whatever anybody tells you about this, make sure you<br>
>> actually do the procedure you choose *before* you're forced to.<br>
>> There's inevitably some learning and tweaking, even if you get recipes<br>
>> from other people.<br>
>><br>
>> So in general, for rsync, I used "-a" plus the option that preserves<br>
>> sparse files ("-S") and the one ("-H") that preserves hard links, and<br>
>> often the one ("-c") that uses checksums to ensure data integrity. Of<br>
>> course, because rsync works over ssh, it's easiest to keep HD2 in a<br>
>> separate machine, so that you can rsync over the network. I use "-x"<br>
>> to stay on one filesystem instead of going into stuff like /proc.<br>
>><br>
>> Some UNTESTED illustrative example commands from memory are below,<br>
>> assuming the only real filesystems on the localhost are / and /home.<br>
>><br>
>> rsync -avSHx / otherhost:/backup-of-hd1<br>
>> rsync -avSHx /home/ otherhost:/backup-of-hd1/home<br>
>><br>
>> The most tricky thing about rsync is probably that trailing slash in<br>
>> the second command. It means "the contents of". Without it, rsync<br>
>> would make a new directory called "home" inside /backup-of-hd1/home on<br>
>> otherhost.<br>
>><br>
>> For the boot sector, I would copy it to a local file before the rsync<br>
>> with dd. But I no longer think that's as good as getting very<br>
>> comfortable with the installation of a boot loader like grub or lilo.<br>
>> There's rarely information in the boot sector that cannot be replaced<br>
>> with something just as good when you're moving onto NEWdrive. Most of<br>
>> the time you can live boot a CD and run grub or something to install<br>
>> the boot loader in the MBR of NEWdrive.<br>
>><br>
>> For the partition table, I used to use sfdisk to dump the partition<br>
>> info to a format that sfdisk can read to recreate the same<br>
>> partitioning scheme. Now I don't think that's necessary either,<br>
>> because if you're doing a high-level file-based backup like rsync<br>
>> does, you can just partition NEWdrive however you want, and it's<br>
>> probably going to be bigger anyway, so good. And maybe you've learned<br>
>> something and NEWdrive will have a better partitioning scheme than HD1<br>
>> did.<br>
>><br>
>> For formatting, I think you mean filesystem creation. In that case,<br>
>> again, maybe there's a better choice for the filesystem on NEWdrive<br>
>> than the one you were using on HD1, so it depends. Because the backup<br>
>> is at the file level, you can choose whichever filesystem is best for<br>
>> your needs. For example, maybe you have 3 partitions on MYNEWDRIVE<br>
>> and want ext3, so you could do something like "mkfs -t ext3<br>
>> /dev/MYNEWDRIVE1" and "mkswap /dev/MYNEWDRIVE2" and "mkfs -t ext3<br>
>> /dev/MYNEWDRIVE3".<br>
>><br>
>> After that, mount that new filesystem use the same rsync options to<br>
>> copy the files from the mounted filesystem of HD2 to the new<br>
>> filesystem on NEWdrive. Something like this is what you'd do on<br>
>> "otherhost" after those filesystem creation commands:<br>
>><br>
>> mkdir /mnt/NEWdrive<br>
>> mount /dev/MYNEWDRIVE1 /mnt/NEWdrive<br>
>> mount /dev/MYNEWDRIVE3 /mnt/NEWdrive/home<br>
>> rsync -avSHx --progress /backup-of-hd1/ /mnt/NEWdrive<br>
>> vi /mnt/NEWdrive/etc/fstab # if you've changed the partitioning<br>
>> scheme or filesystems<br>
>><br>
>> These commands are pretty darn close, but they're untested and<br>
>> provided without warranty. If anyone sees errors, please chime in.<br>
>><br>
>> OP, please practice using them inside virtual machines or something<br>
>> until you're as comfortable as anyone else if you intend to do this<br>
>> when other people are counting on it working successfully.<br>
>><br>
>> On Fri, Mar 2, 2012 at 1:38 PM, Courtney Thomas<br>
>> <<a href="mailto:courtneycthomas@bellsouth.net">courtneycthomas@bellsouth.net</a>> wrote:<br>
>>> ...(1) back up all their filesystems from HD1 to an archive hard drive HD2,<br>
>>><br>
>>> (2) then replaced HD1 with a NEWdrive which was partitioned, labeled and<br>
>>> formatted exactly duplicating the replaced HD1, and then<br>
>>><br>
>>> (3) RSYNCed the archived files on HD2 to the NEWdrive, with the result that:<br>
>>><br>
>>> the NEWdrive was not only without fault, but that the previous<br>
>>> functionality<br>
>>> of HD1 was exactly duplicated ?<br>
>>><br>
>>> If yes to all 3, would anyone care to share<br>
>>><br>
>>> (1) the RSYNC backup command for HD1 -> HD2<br>
>>> (2) their partition, label and format commands for NEWdrive<br>
>>> (3) the RSYNC restore command for HD2 -> NEWdrive<br>
>>><br>
>>> This is obviously of overwhelming importance to all and if anyone can<br>
>>> point to a<br>
>>> reliable source, or provide it outright themself, for the above sought<br>
>>> command<br>
>>> summary, my gratitude would be boundless :-)<br>
>>><br>
>>> I am aware that rsync, fdisk, e2label and mkfs are all documented commands,<br>
>>> but a successful usage, as herein outlined, is, at least in my case,<br>
>>> frustrating<br>
>>> days away of trial and error, having already wasting such time in<br>
>>> pursuit of such<br>
>>> an outcome using 'dump'.<br>
>>><br>
>>> Sincerely,<br>
>>><br>
>>> Courtney<br>
>>> _______________________________________________<br>
>>> Ale mailing list<br>
>>> <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
>>> <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
>>> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
>>> <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
>><br>
>><br>
>> --<br>
>> Ed Cashin<<a href="mailto:ecashin@noserose.net">ecashin@noserose.net</a>><br>
>> <a href="http://noserose.net/e/" target="_blank">http://noserose.net/e/</a><br>
>> <a href="http://www.coraid.com/" target="_blank">http://www.coraid.com/</a><br>
>><br>
>> _______________________________________________<br>
>> Ale mailing list<br>
>> <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
>> <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
>> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
>> <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
> I am using rsync to back up zipped copies of configs and whatever else<br>
> is needed. This is not a 1:1 of the whole originating disc<br>
> partitions, as you say you want - but just the important pieces.<br>
> Presuming the original drive doesn't fail, but only some piece of the<br>
> puzzle failed, it is still a manual task to recover the piece you<br>
> need. My thinking is that if the original drive fails, I have either<br>
> ZRAID or a system snapshot to return me to the original OS state, and<br>
> the only thing I am missing is the recent data.<br>
><br>
> tar xzf thearchive.tar.gz<br>
> rsync -avz the-directory-you-need root@yourserver.com:/path-towhere-it-goes/<br>
><br>
> This is one of the most common errors with rsync as well, in that it<br>
> is a basic reversal of the original rsync command. B -> A rather than<br>
> A -> B<br>
> If you are going to be running your rsync from a 3rd machine, as you<br>
> would have to be doing if you are replacing whole disc-images, I<br>
> think, you would have full paths at both ends of your command.<br>
><br>
> Ed ++<br>
> Always test major file-moving on VMs before you trust the process on<br>
> your production machines.<br>
><br>
> Wolf<br>
><br>
Wolf,<br>
<br>
Thank you for your response.<br>
<br>
Having not used rsync, why are 3 machines necessary to make whole disk<br>
copies ?<br>
<br>
Why can't an unused disk on the syncing machine be sync'd with the<br>
desired disk, wherever it's located, including on the syncing machine ?<br>
<br>
Cordially,<br>
<br>
Courtney<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>