Making my Own Images?

rsync your data.

Script/document your application installs.

Backup/document your config files.

What would an offsite image do that the above 3 steps won't (and you have to do the first one no matter what your recovery plan/method is)?

Right, that's the only solution I came up with.

I was more curious if it was possible to make a disk image that I could just deploy to my linode. It would be more convenient, in my eyes, to make a disk image that I could use to just reinstall the system as-is and everything is back, data and all.

@joshvickerson:

I was more curious if it was possible to make a disk image that I could just deploy to my linode. It would be more convenient, in my eyes, to make a disk image that I could use to just reinstall the system as-is and everything is back, data and all.
It's possible, but if you're trying to store it remotely, backup/restore times could be significant depending on image size. It'll also involve downtime, though you can minimize that by temporarily using a second Linode, cloning the image to it, and then doing the network transfer from that while the original Linode is returned to operation. See http://library.linode.com/migration/ssh-copy for one method for how you could make a copy of a raw disk image to be stored elsewhere. If it's not the boot device, you could do something similar from the running Linode if you can unmount the device first.

Or, if you have enough free space with your Linode, you could just duplicate the disk and keep it locally as a snapshot that you could restore, but that would only protect against messing up the main image, not a failure of the Linode itself.

Assuming you implement a finer grained backup approach to further changes, you could presumably use this as a one time disaster recovery starting point and then use the other backups to bring a restoration up to date. But if you want to take periodic full image snapshots, Linode backups will probably begin to look a lot more attractive.

– David

@db3l:

Assuming you implement a finer grained backup approach to further changes, you could presumably use this as a one time disaster recovery starting point and then use the other backups to bring a restoration up to date. But if you want to take periodic full image snapshots, Linode backups will probably begin to look a lot more attractive.

Yeah, that's my primary goal; give myself a one-time disaster recovery point that could be potentially faster than redeploying a fresh Ubuntu image and restoring critical services and backups of configurations.

Thanks for the help! :)

One other question, I assume the disk image would not include any unallocated space?

So, if I shrunk the running image down as much as possible before copying the image, the image would be smaller as well?

If that's the case then it's just a matter of reallocating the space if the image is ever needed. Shrinking the image has obvious benefits.

@joshvickerson:

One other question, I assume the disk image would not include any unallocated space?
It's a raw device copy so it'll be as large as the image, regardless of how that space may be allocated (or not allocated) by the filesystem within the image. I'm not sure if Linode images are zeroed initially, but it's possible if made early after the image was created that it might compress well (you could do it over the network transfer too) if mostly empty.

> So, if I shrunk the running image down as much as possible before copying the image, the image would be smaller as well?
Yes, that would be a good way, at the point of the initial copy, to be sure to minimize the data to transfer/store.

Note that you get somewhat similar behavior automatically with the Linode backups. If you choose to restore a backup/snapshot, it re-creates disk images but just large enough to contain the restoration. You can then grow the resulting images afterwards.

– David