Storage always full (Free: 0 MB)

If you're looking at the storage box in your Linode Manager, that's your space allocated to disk images, not your space used inside those images. To see your space used inside the image, log into your Linode and run "df -h"

Many thanks for the reply. df does show most space free.

Sorry to drift the question but the reason I ask is I'm wanting to test the backups and snapshots.

If I wanted to restore a snapshot, which I have taken yesterday, it says I have no space, so I have to remove the main disk image first ?

You can remove the image or shrink it down in your Linode Manager > Dashboard > Edit link next to the image. On the next page you'll be able to select a new (smaller) size. After you shrink the image, you should be able to restore without deleting. To find out how much space you need, just click the "Restore to" link by the image you wish to restore from in your Backups tab.

Great, And will any resizing of my live image effect/lose any of my current working setup ?

Nope, but you do have to shut down your Linode prior to shrinking your image

Thanks for the replies.

So far I'm loving the product and support.

You could also create a new node in the same data center and restore the backup to that. (Since everything is prorated, if you delete one of the nodes right after that, you'll only be out one day's fee.)

Sounds good.

So in case of any system problem we could add a new node, restore a backup, then deleted the old node or investigate later.

This sounds too easy.

What about IP address etc, would this be correct for the new node or transferable ?

Yep, pretty much that easy.

By default the new Linode will have its own IP address, but you can swap IP addresses between two Linodes (in the same DC) from within the manager once you are ready to bring the new node online.

You can also set up a high availability setup where an IP can be shared (though obviously only used by one node at a time), but in the case of a new node for restoration, swapping is probably a better fit.

Of course, space permitting you can also transfer any repaired images back to the original node (even if you first blow away its own images for space) to return to operation on the original node, if you happen to like the host, or whatever. I suppose one small benefit of that would be maintaining the persistence of older backups which would have to restart if you cut over completely to the new node.

– David

Many thanks

Sorry one more question…

The restore to a new Node seems to work well.

If I have space on my current node can I restore to the same node then if I get a problem or break something during my tests I can quickly switch to the restored 'Configuration Profile - Restore 7998 - My LAMP Stack Profile' and reboot, and am back to the same setup when it was backed up ?

Or just create the new 'Restored Configuration Profile' when I need it so the image doesn't get too old.

@markunit:

If I have space on my current node can I restore to the same node then if I get a problem or break something during my tests I can quickly switch to the restored 'Configuration Profile - Restore 7998 - My LAMP Stack Profile' and reboot, and am back to the same setup when it was backed up ?
Yes. You may also wish to make use of the snapshot feature if you are planning your test changes, so that you can get a backup immediately prior to the point you begin making changes rather than the most recently nightly backup.

(If you can afford any down time, temporarily shutting down and cloning your disk images is probably a faster way to do this too)

> Or just create the new 'Restored Configuration Profile' when I need it so the image doesn't get too old.
Your call, but you've identified the key difference which is state of the system you'll restore to with a dated backup.

Personally I wouldn't think a backup even mildly old would be much good for more than an emergency (and perhaps read-only setup while you tried to get more recent stuff restored), but that's heavily dependent on your environment, how often it changes, how you may back up more frequently changing elements, etc…

For example, one of my nodes that is largely a static site could easily get by in a pinch with pretty old backups as the basic recovery mechanism, but that's also because I can quickly update the more frequently changing elements out of a central revision control repository.

-- David