Linode backup, I suppose that is exited from the beta...
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.
17 Replies
is there someone using the backup service from linode?
@jed:
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.
yes, I need it,
thanks.
"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?
@sblantipodi:
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.
@pclissold:
@sblantipodi: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.
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:
do you know if there is some sort of encryption on the backup side?
@sblantipodi:
is this service still in beta?
It's in production. See. here
@sblantipodi:
do you know if there is some sort of encryption on the backup side?
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.
@pclissold:
@sblantipodi:is this service still in beta?
It's in production. See. here
@sblantipodi:do you know if there is some sort of encryption on the backup side?
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.
you are right
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?
@sblantipodi:
don't you think that a block to block backup is better than the actual file backup?
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.
> 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?
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.)
> 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?
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.
you are right.
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?
@sblantipodi:
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
but why, we can create a linode also for a day?
the minimum isn't a month subscription?
@sblantipodi:
really thanks also for your answer db3l,
but why, we can create a linode also for a day?
the minimum isn't a month subscription?
If only a single Linode was involved I'd agree that in practical terms you can't really get it for just a day. But when creating extra Linodes on an account, you can remove them when done, and the prorated balance of anything you were charged for those Linodes (e.g., the rest of the initial invoice until the end of the current month) goes back into your account, and can then get used to offset the next month's charge of your existing Linode. (At least that's my understanding)
So as long as you keep some Linodes active in your account, you'll catch up with charges for your short-time additional Linode. And if you keep at least as many Linodes as you create short ones, it should catch up in no more than a month. The net effect is that the only extra money you should pay overall is the prorated cost of the extra Linode(s) for the days you kept them.
You could actually do this with a single Linode too, but in that case you'll have a positive balance in your account until you eventually create a new Linode to make use of it.
– David