Downsize Linode 1024 to Linode 512

Everything will move along! It'll take some time with your Linode offline, but everything will be preserved as it is. When you're ready to go, shut down, resize your disk image to 16 GB or less (aim for 15500 MB or so), then go to the Resize tab and do the resize. You'll get a credit on your account for the difference.

I'm new to Linode and looking to downsize my 1024 to a 768. Forgive all the scenarios here, but I'm trying to understand all my options to build confidence in maximizing the use of your platform. I will need to ramp my services up and down from time-to-time. Upsizing is obviously straight forward.

In the Resize menu, I've notice that i can resize directly without making any modifications. Out of curiosity, what happens if I downsize without first shutting down and resizing my disk image?

What would happen if I downsize my disk image without shutting down first? Would it automatically shutdown first, then resize, then reboot?

I assume that all the above, will only remove unused space, leaving my system and data fully intact?

Assuming I wanted zero downtime, would either of the following process work:

1) snapshot the Linode; create a new smaller Linode from the snapshot; move the IP address to the new Linode

2) snapshot the Linode: make a new clone Linode from the snapshot; downsize the disk image on the new clone; downsize the Linode size of the new clone; move the IP address to the new Linode

@incolor:

In the Resize menu, I've notice that i can resize directly without making any modifications. Out of curiosity, what happens if I downsize without first shutting down and resizing my disk image?

Well, if the disk images are the right size I believe it warns you that it's going to power down your instance and migrate you. If you approve it powers you down and migrates you. If the disk images are too big it tells you beforehand.

@incolor:

What would happen if I downsize my disk image without shutting down first? Would it automatically shutdown first, then resize, then reboot?

The job will fail mentioning something about your Linode not being powered off

@incolor:

I assume that all the above, will only remove unused space, leaving my system and data fully intact?

This is correct.

@incolor:

Assuming I wanted zero downtime, would either of the following process work:

1) snapshot the Linode; create a new smaller Linode from the snapshot; move the IP address to the new Linode

2) snapshot the Linode: make a new clone Linode from the snapshot; downsize the disk image on the new clone; downsize the Linode size of the new clone; move the IP address to the new Linode

If you are using the Linode Backup Service, and your utilized space is less than (or equal to) the Linode 512 disk space both should work. If you are using the Linode Backup Service you would add the new Linode, and then restore your backup to the new Linode.

You would, of course, want to make sure they are in the same facility.

-Tim

Excellent! Thank you for your fast response.

So I should purchase a new Linode in the same facility, perform the restoration of the snapshot to the new Linode (utilized disk space is small enough), move the IP address, then terminate the original Linode?

Upon termination, will the prorated, unused amount (Linode and backup) automatically be credited back to my account? Then at the end of the month, will all credits be applied first before new charges are applied to my credit card?

@incolor:

Excellent! Thank you for your fast response.

So I should purchase a new Linode in the same facility, perform the restoration of the snapshot to the new Linode (utilized disk space is small enough), move the IP address, then terminate the original Linode?

Upon termination, will the prorated, unused amount (Linode and backup) automatically be credited back to my account? Then at the end of the month, will all credits be applied first before new charges are applied to my credit card?

For minimal downtime purchasing the additional Linode is the best option.

When removing the old (original) Linode you will receive a prorated account credit for the Linode and Linode Backup Service. The billing system will then use this credit toward all future invoices. Once the credit runs out, your card will be charged the difference.

Also, make sure you enable the Linode Backup Service on the new Linode if you want it.

-Tim

I started the restore of my backup snapshot to my new Linode 768 over 26 minutes ago, and it has been stuck on 3% restored for the last 25 minutes. The snapshot was of a Linode that had only 7.3GB of data on it.

Something's wrong!

@incolor:

Something's wrong!
Best thing to do is open a support ticket.

– David

So, the official response is that a restore from snapshot takes "somewhat longer than the actual backup," where the word "somewhat" means 1GB per hour for restore.

Does anyone else think this is unacceptable for an on-site backup solution?

what basis of comparison are you using for saying that it is unacceptable?

Amazon Web Services can create a bootable snapshot of a 25GB server in about 20 minutes. Then it can restore it to a new, booted server in about 3-4 minutes.

I know the system here is much different, but c'mon. This process shouldn't take more than an hour or two at the most. That same 25GB server would take on the order of a full day to restore? I know my customers wont wait that long.

It seems as if your complaining about something that should have, little to no negative performance impact on your customers.

I don't see the point on complaining, as it won't help.

Complain if you want; but like I said, it seems rather pointless to do.

I don't see all the long-time Linode users complaining about Linode's performance and such. If they do, I don't hear about it a lot on the forums.

Also, might I point out that if you really want, you can just move to Amazon's servers then, so that you don't have this problem? Their are always solutions such as simply moving from Linode to Amazon instead should you feel that to be a beter option.

That being the case, Linode is not for all, it wasn't meant to be. That's not what LInode is around for, they aren't around to force anyone to use them as a provider. I'm sure that some customers have tested Linode long enough to complete a referral program, only to discover perhaps that they find something else of interest, and move on in general.

Does that seem possible?

I'm sure that after the fact, sooner or later those same people come back to Linode.

Please don't complaintoo much about Linoe's snapshotting technology.

You are using public bandwidth consuption, at least I think you are during migrations, updating/downgrading, etc.

Am I corect in this?

If so, then doesn't that use of bandwidth count against your monthly quota of over all permitted bandwidth?

Thanks!!

I hope this has calmed down the complaining just a bit.

:)

Take care.

@incolor:

So, the official response is that a restore from snapshot takes "somewhat longer than the actual backup," where the word "somewhat" means 1GB per hour for restore.
Hmm, so far in my experience of restoring from snapshots, it hasn't been anywhere near an hour per GB, at least for the restorations I've done.

One possibility - just guessing - is that we're in the window where perhaps a majority of the backups are scheduled to take place, so contention on the backup servers may be at its worst, and represent a worst case scenario for a restoration.

If you're really seeing a GB per hour (based on the full restoration, since it may pick up again) on average, can't say I'd disagree with you that it's slow. Doesn't necessarily make it "not a feasible" system, but it may be an issue depending on requirements.

– David

[comment removed by author]

I acknowledged my understanding that this is a different platform. I was merely demonstrating a serious weakness that I calculated while doing a restore.

This calculation was based upon feedback that your platform presented to me. It gave me the time in seconds, followed by percentage of completion of the restore process. I did a simple calculation several times during the process and came up with the same ballpark figure of one hour per gigabyte.

I doubt anyone would disagree that one hour per gigabyte is absolutely worthy of complaint.

As it turns out, the percentage completion progress feedback is not correct (or more precisely, it's not linear). Somewhere after 10%, it must have jumped to completion in a matter of a few minutes; I wasn't watching. This is after taking over fifteen minutes to get to 3%. Apparently, the whole process took about an hour to complete for 7.5GB.

As I stated above, an hour is acceptable. However, that's not what the feedback implied the duration was to be.

The law of significant figures dictates that when you provide data in units of seconds and percentages, calculations based upon those values should be accurate to that level of accounting.

So, my (legitimate) complaint is that your accounting of progress is highly inaccurate, and therefore very misleading. I suggest you either recalibrate the feedback or remove it. Another option would be to provide it in 10% increments, etc. It does not help to have severely misleading information.

As an aside to this specific issue, you should never chide a customer for complaining. I did not use foul language, and I did not attack you personally, so why squelch my complaint? I was just getting started with Linode. Are you really suggesting that I take my business elsewhere?

I suggest you read Managing Knock Your Socks Off Service (Bell & Zemke, 1992). Chapter 7 is entitled "A complaining customer is your best friend." Most unhappy customers won't tell you what (they perceive that) you're doing wrong. They will avoid confrontation at any cost, and simply quit your business. Don't tell them that you're not interested in knowing how to make your business better (from their perspective).

incolor, the only person in this thread who actually works for Linode is theckman, and he was perfectly nice. For better or for worse – and it's usually better, in my opinion -- the Linode forums are not ruled with an iron fist, so unfortunate things sometimes happen.