Clone a Linode's Configuration/disks to another Linode

This feature enables you to clone a Linode's configuration and data over to another Linode that is linked to your account. You can select an entire configuration profile to clone -- and this will automatically create the configuration profile in the target Linode, and copy all disk images associated with that configuration profile over to the targeted Linode -- or, you can pick out individual disk images to copy over.

This new feature is located here, off the new Utilities sub-tab.

Implementing this was more complicated than I initially thought, so some testing would be appreciated. Keep in mind, copying large disk images across datacenters will take time.

Enjoy!
-Chris

Coolness! This would be very handy setting up redundancy across datacenters...

Or even within the same data center, with Linodes on separate hosts and using the new HA / IP Failover feature:

http://www.linode.com/forums/viewtopic.php?t=2933

What are you guys trying to do, put all of your competitors out of business??? How can they avoid bankruptcy if you keep this up?

James

Wow. What a useful feature. I really appreciate you implementing this. It makes testing changes to a production server so much easier without the need to shut it down for long periods of time.

Are we still being "charged" for the bandwidth this process would use?

If yes; can you make it possible to run two linodes on the same physical server so that any backups of this kind would be from localhost to localhost and thereby not generate any traffic on the network? That way you could choose not to charge for the bandwidth generated by a backup process.

The copies run from host to host, rather than from within a Linode to another Linode .. if that makes sense. So, no -- this isn't deducted from your transfer allotment.

Enjoy -- let me know if I missed some bugs

-Chris

I assume the OS better be configured for DHCP else the same IP address might come up on both linodes...

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

It makes sense. And is wonderful!

I just finished backing up my production linode disk image to my other linode. They are both in the same data center (Atlanta) and the backup of 2048 MB took 10-11 minutes. I tried to not shut down the running production server before clicking the "clone button" just to see if it would work anyway. It seems to have worked. Me and 2-3 other users are the only users of it, so I guess it worked due to very low disk usage on my production server.

Anyway.. I edited a mediawiki page on one of the servers and clicked refresh on both. The update only registered on one of the servers which is how it should be. I haven't done any more testing but it seems that this cloning feature you have implemented works just as I expected.

I noticed that the Dashboard job only got visible on the receiving linode account and not on the sending linode account. That is no biggie but would be nice if you fixed.

Unlikely. The MAC address of a linode is based on it's bridge, which I think is some magic caker sets up to be unique.

That controls your IP, *if* you're setup with DHCP. But if you modified your config for a static (as in fixed, hardcoded) IP, and then replicate that disk to another linode, it would be Not Good.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.
-- seen on the net

We filter layer 2 and layer3 traffic, in and out, that does not belong to the Linode in question. So, worst thing that can happen is that it boots without an accessible IP address.

Now, if you have the IP Failover stuff configured to allow those IPs to come up elsewhere, then yes -- it'll be bad.

-Chris

Caker, I'm finally getting around to giving this a try. I've bought another node (taking advantage of the new instance-day feature!) in order to test out an OS update on a clone before I do it on the real server. Had a couple of thoughts:

a) Is the data being run through a quick gzip or other compressor before being sent? From my back-o'-the-napkin calculations, it doesn't seem to be, although it could be that the data being sent was already compressed when I sampled.

b) I told it to clone before having any idea how long it would take, and then wished I could cancel the jobs and just clone one or two partitions, but I don't think I can do that at the moment.

c) The jobs appear on the "to" Linode, so I can submit a boot job and it'll happily boot after the transfer completes. But the jobs aren't on the "from" Linode at all, so I can't just submit a boot job for my existing server and go to bed while the transfer finishes.

Problems? I see what looks like a problem with the links mentioned above. What is going on??

_________________
Q.E.D

Rob

You're reading an announcement from some years ago; since then, the dashboard has been reorganized and older URLs probably won't work. Fortunately, it's still there on the Settings & Utilities tab in the dashboard, almost exactly as described.