duplicate image

Hi, just started using Linode yesterday, fantastic so far… :D

Quetion: will I get a corrupt copy if I duplicate my disk image while it's mounted ?

I like the way my ubuntu server is configured now, so I'd like to keep an exact copy of the root partition so I go back to it if I mess up later… and of course I have some free space to do that. But I'm not sure if I'll have to take my linode offline before duplicating my disk image. I found a few threads on related topics, but most of them are old so I'm not sure how things are with Xen servers….

Thx

5 Replies

You'll get a copy where open files are in undefined states - as if the machine had been suddenly powered off. If you are using a journalled filesystem, this shouldn't matter in theory, but the copy is not instantaneous like a power-down so the results are hard to predict. Since this will be the backup you rely on after the original has been trashed, play it safe and shut down while you duplicate.

following on from this…

how safe is it to resize one of my existing images (shrink it) so that I can make room for a duplicate image?

@chrisnolan:

how safe is it to resize one of my existing images (shrink it) so that I can make room for a duplicate image?
Resize has always worked OK for me - but something like a power outage halfway through the operation could screw it up. Run your offsite backup first.

Thanks for your explanation, pclissold

@pclissold:

You'll get a copy where open files are in undefined states - as if the machine had been suddenly powered off. If you are using a journalled filesystem, this shouldn't matter in theory, but the copy is not instantaneous like a power-down so the results are hard to predict. Since this will be the backup you rely on after the original has been trashed, play it safe and shut down while you duplicate.
No, this is not the same as a sudden poweroff. Since the linode is modifying the filesystem at the same time, you can (and probably will) end up with massive corruption - and your journal will only make things worse, as the kernel might not notice the corruption until it's already made it worse. If for some reason such a thing was /absolutely necessary/ for some insane reason:

  • Quiesce the source filesystem as much as possible first

  • Copy the fs

  • Forcibly remove the journal from the copy with debugfs

  • Run e2fsck -f

  • Pray (but don't get your hopes up)

In order for the copy to truly be sound, it absolutely needs to be made atomically.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct