Hi all,
I have some questions.

Suppose that I have the backup service enabled.
Something on my linode happen, something that I don't like, imagine a system file corruption for example.
Suppose that the system can't boot due to the system file corruption, is it possible to use backup to restart the system?

Is a problem occur, the "file backup" offered from the new backup service, will be powerful as much as the disk image copy from the linode manager? If yes, may I delete the disk image copy from my linode and completely rely on the file backup?

Thanks.

it is really interesting that with more than 200 views no one answered yet.
is there someone using the backup service from linode?

A backup restore creates a disk image with the filesystem that was on it when the backup happened, so I don't see any reason why you couldn't restore a Linode to a running state from a backup. Undoubtedly, it supplants the copied image you have now.

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

yes, I need it,
thanks.

from a support ticket:
"The backup service will backup the data files for your DBMS. In order to guarantee a consistent backup, it is recommended to dump your databases to file somewhere on the filesystem and allow the backup service to backup that file instead."

I haven't undertood why...
Backing up the data files for DBMS isn't equivalent to backup a dump file?

I'll try to explain better what I mean, if I backup all the data files for DBMS, and than restore this file, after this operations I have a working, updated database. am I wrong?

If the database system updates the data files during the backup, the restore may produce an internally inconsistent database. Using the database system to dump to a file ensures that you have a consistent database in the backup, regardless of what changes are made to the live database during the backup process.

_________________
/ Peter

The biggest thing to worry about is a half-finished transaction that the backup jumps in the middle of. Same with any backup solution, ours or yours. I know most RDBMSen can recover from that, but others cannot (and do you want to chance it?).

File modifications after the backup starts don't go into that backup, so it's just half-finished things at the start (package manager upgrades, SQL transactions, etc) that might make a restore less than optimal. I always recommend keeping a backup you know is good as your snapshot -- you know it's good because you put the system in a backup-friendly state and then pushed the button -- and cron your database to dump to a file before your backup window for best results.

Chris said it well here: http://blog.linode.com/2010/05/04/intro ... ment-51549

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

is this service still in beta?

do you know if there is some sort of encryption on the backup side?

It's in production. See here.


Why would there be? It's just another file on a Linode server, like the disk images on your Linode. If you are storing stuff that that needs to be encrypted, it should be encrypted on your 'node.

_________________
/ Peter

you are right

don't you think that a block to block backup is better
than the actual file backup?

With the disk image clone from the standard dashboard we can backup all file system, no file attribute problem.
Why they choosed the file way?

Anyway, I bought the backup service for 12 months because I like the 4 rotating slot.
Before I bought the backup service I used to backup my linode manually using the linode dashboard by cloning the image,
do you think that is safe to delete my cloned images and enlarge the "in use" disk image?

If you're doing a single backup of a single machine, sure. However, storing raw disk images scales very poorly once you start doing multiple incremental backups of numerous systems. Keeping 4 full block-level backups of a Linode 360 will take 48GB; that's a lot of disk.



Show of hands: who actually uses acls and file attributes? They're relatively rare. If you do, I recommend whipping up a script to crawl the filesystem and dump out a list for future restoration. (Like a mysqldump, but for a different database.)



Up to you. For what it's worth, you weren't really backing up your system by cloning the images, since you'd still lose everything in the event of a storage failure, so you're coming out ahead now. But that's just pedantry.

thanks for your reply hoopycat,
you are right.

last question:

if I click on the "Restore to" link on the backup tab of my linode manager, I get the "not enough free space" error.

This means that I need to delete all my disk image from the dashboard before restoring the backup?

Well, more literally it means you need enough free space on the machine you are restoring to for the data being restored.

But yes, if the backup is larger than the unallocated disk quota you have on your Linode, you won't be able to restore a backup to that Linode without freeing up some space.

Now, if your Linode has crashed or all the data been lost, that's not much of a big deal since presumably that's why you're restoring.

But if your Linode is still functioning and you want to restore for some other reason, what I'd recommend is creating a second Linode (even if just for a day) and restoring to that. You can double check that it works (careful when booting if you have hardcoded IP addresses or other services that may conflict with your main Linode - you may want to disable them through a recovery configuration first).

If all looks good, then you can blow away the original disk images and then clone the images between the two Linodes - or just switch their roles and start using the new one. Or if you just needed one of the images from the backup it may be possible to clone that single image back to your original Linode, space permitting. Options abound.

-- David