Disk cloning redux

[Harald_Jensas at Dell.com]

> -----Original Message-----
> From: linux-poweredge-bounces at dell.com [mailto:linux-poweredge-
> bounces at dell.com] On Behalf Of Dimitri Yioulos
> Sent: den 23 januari 2009 14:17
> To: linux-poweredge-Lists
> Subject: Disk cloning redux
> 
> Hi, folks.
> 
> At the risk of earning your scorn and enmity, I'd like to ask once more
> about
> how I might proceed with a disk cloning project.  I have certainly
> appreciated everyone's feedback, but am not sure I've gotten a
> definitive
> solution  Once again, here are the key
> 
> -- system to be cloned is remote; no access but for minor tasks (e.g.
> hard
> reboot)
> -- system resides in its entirety on sda
> -- need faithful reproduction of sda on sdb in order to save Ensim
> installation, and as DR mechanism
> -- no RAID or LVM on system
> -- down time not an option (so not able to use Clonezilla, G4L, etc.)
> -- active MySQL databases
> -- have heard/read that:
>          * dd shouldn't be used on systems with open files
>          * creating software RAID post-system installation may lead to
> data
> loss
> 
> But, because I've also read/heard that others have used dd for this
> purpose,
> I'm still leaning toward it.
> 
> Any final thoughts, ideas, tips, tricks, etc.  Or, again, am I SOL?
> 
> And again, thanks for your patience and input.
> 
> Dimitri

dd will defenetly not work in your case, since you are cloning a live/online system!

**** dd will sequentially read you device and write it to another device. ****

Scenario: 
dd have passed 100MB into the source device, then your application update/write to data 50 MB into the device. The updated information will never be replicated, and you have an unconsistent and useless filesystem on your target device.

To use dd you would have to take the system offline, unmount the filesystems to make sure no changes are made. Remember that even mounting the partition read only updates the information about when filesystem was last mounted.

You have 1 option and I doubt you have the functionality needed...

1. Disk Controller system or LVM system that can do a point-in-time SnapShot, then track changes since the point-in-time SnapShot. 
This would be the process:
- Flush you filesystem buffers.
- Take a point-in-time snapshot of source drive.
- Replicate snapshot to target drive.
- Once replicated flush filesystem buffers again.
- Use tracked changes information to replicate changes to target drive.
- Replicating the changes should be faster this time and, after repeating the step n number of times you should be able to take source filesystem offline and do a quick last transfer of changes and get to a fully synchronized state.

If you only need to clone the system once I suggest you take the system offline for maintenance, do the cloning. 

But remember! 
What use is that clone to you in 2 weeks? Or 1 month?

If you have to take the system offline again in once every few weeks or months to make sure you cloned data is recent enough to meet your DR recovery point objective this is probably not going to be the route to go anyway.


I would recommend going back to the thinking box and figure out What do I want to protect against? 
- Drive failure? (In this case, get RAID Mirroring)
- DBA having a bad day and drops the wrong SQL table, someone delete a file by mistake? (Use Backup or/and SnapShots or/and clones)
Etc.


--
Harald Jensås