Date: Fri, 8 Jun 2012 18:12:05 -0700 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Warren Block <wblock@wonkity.com> Cc: Robert Huff <roberthuff@rcn.com>, freebsd-questions@freebsd.org, "Ronald F. Guilmette" <rfg@tristatelogic.com> Subject: Re: Making a bootable backup (hard)disk... how? Message-ID: <CAOgwaMv-rB5ay_Nw8YfRX0xjJoaa8HarVKdCtGneB9O7VmxUXg@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1206081746150.62743@wonkity.com> References: <2903.1339191855@tristatelogic.com> <20434.30642.31558.246729@jerusalem.litteratus.org> <alpine.BSF.2.00.1206081746150.62743@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 8, 2012 at 4:58 PM, Warren Block <wblock@wonkity.com> wrote:
> On Fri, 8 Jun 2012, Robert Huff wrote:
>
>
>> Ronald F. Guilmette writes:
>>
>> I got a lot of disks here, so that part is not a problem. I just
>>> need to make sure that I'm gonna do this the Right Way[tm].
>>> (I've already been making my own ham-fisted disk-to-disk backups
>>> in the past, but I'm sure that the way I have been doing that is
>>> sub-optimal, so I'm here seeking knowledge of how to do this the
>>> Right Way.)
>>>
>>> The bottom line is this... I know how to use cpio, and would like
>>> to use it to create a complete and _bootable_ backup of my main
>>> system disk. (My main system disk has only one BIOS partition,
>>> and that is sub-divided into the usual set of FreeBSD partitions,
>>> you know, /, /dev, /tmp, /usr, /var, /usr/compat/linux/proc, and
>>> /var/named/dev.)
>>>
>>
>> As far as I know, the only way guaranteed to preserve metadata
>> is dump/restore. See previous (not necessarily recent) discussion
>> (on this list, and possibly in the Handbook) for more information.
>>
>
> The rsync port has a flags option. I haven't tried it for a full backup.
> Even if it can copy all filesystem attributes like dump, there are still
> non-filesystem things needed for booting that neither can copy, like
> partition tables and boot blocks. There might be something for a bootable
> backup in ports, or it could be done with a script using gpart. Set up the
> disk with GPT labels to make it relocatable, use dump to copy everything
> the first time, fix up a few things like fstab and ifconfig_DEFAULT in the
> same script.
>
> Afterwards, rsync may be enough for fast updates.
>
I am applying the following technique in Linux ( because I am not using
FreeBSD ) :
On the same computer :
(1) I am disconnecting power cable of the existing HDD .
(2) I am connecting a new disk ( by attaching Channel Zero SATA Cable to it
) .
(3) I am installing a new operating system on HDD
(4) I am installing mc ( Midnight Commander ) .
(5) After obtaining a working new HDD , I am connecting the power cable of
the previous disk .
(6) I am booting the computer . The new operating system is "seeing"
previous HDD .
(7) I am mounting previous HDD .
(8) By using mc , I am copying required files/directories into new HDD .
Mostly I am using KDE4 . Dolphin in KDE4 has a memory leak which is
causing disaster for very large list of files
because for each file , it is consuming irrecoverable memory loss from
600 bytes to 1000 bytes during copying .
(9) I am keeping previous HDD as bootable by disconnecting its power cable
because it is not necessary to keep
it powered .
You can do the following :
(1) Install your operating system on back-up HDD .
(2) By using a script , copy required files /directories onto back-up HDD .
With this technique , you can maintain a revolving back-up HDD units :
Create back-up HDD 1 .
Create back-up HDD 2 .
.
.
.
Create back-up HDD n .
When n-th HDD is created , and a new back-up is required switch to HDD 1 .
Using rsync you may update only required files / directories . Full copy is
not required to update subsequent HDD units because it is very likely that
many files are the same .
In that form , EACH back-up HDD is bootable when it is required .
You may consider HAST for a single HDD .
You may use external USB HDD by selecting a robust model .
Disconnecting power cable of existing HDD during a new operating system
install on another HDD is preventing an accidental loss of data because
naming the recognized HDD units is NOT standard and very unreliable .
Thank you very much .
Mehmet Erol Sanliturk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMv-rB5ay_Nw8YfRX0xjJoaa8HarVKdCtGneB9O7VmxUXg>