Re: Backup OEL Virtual Machine

From: MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
Date: Tue, 21 Jul 2015 13:05:46 -0400
Message-ID: <CAAaXtLA4VFuEnbgGwAWw9-dZdkNPxwJ7uq6OiwzGSKEc=DBCtQ_at_mail.gmail.com>



Hmmm... I think I would be careful with that approach.

Simply "copying" the files constituting the state of your VM would give you a backup of a sort, but it would be (at best) equivalent to making a "backup" of a physical machine by copying all of the disk partitions with something like 'dd'. This *can* give you a recoverable image but:

  • The backup image is only reliably recoverable if the backup was "cold"
    • in this case, if the VM is not running at the time the backup was made.
  • Recovery options will be VERY limited -- you can restore the VM only on an all-or-nothing basis.
  • You can restore only to the state that existed at the time of the backup. There will be nothing even approximating "point in time" recovery capability. (What happens, for example, when you want to restore a single crontab file to the state it had yesterday?)

The first problem here is probably being covered by the OP's hypervisor when he makes a "snapshot". He reports that the VM appears to "stall" when the snapshot is being made; this is probably the hypervisor protecting the validity of the backup image by quiescing the VM. (A very smart hypervisor will probably only quiesce the VM when it issues the first write request for any "disk" being snapped, but if those disks contain your swap space, or even your Oracle alert logs or listener logs, it probably won't take a long time for such a request to occur.)

If you *must* copy the files underlying the VM. I would think that the smartest way to do so would be to use the snapshot functionality built into the hypervisor (if any).


Sadly, though, disk-image backups of any sort address only a small set of recovery scenarios.

Personally, I would want at least some capability to recover individual files from backup. There are a number of configuration files where a botched edit can cause absolute havoc. It would be a great comfort to know that I can always restore these files to a previous "good" state, even if that state might be 24 hours (or a week) in the past.

I would not, however, want to have to restore the entire machine to a prior state -- that would require *downtime*, and nobody likes that much. :-)

[Sadly, I have encountered numerous customer sites in the past where a botched edit on /etc/hosts or /etc/inittab very probably *would* require a complete restore of a machine image, precisely because the only backups made of the OS configuration files are machine-level snapshots. I have never felt comfortable working in such environments.]

There are probably lots of cases where image-level backups (or snapshots) are perfectly adequate, of course. But there are also lots of cases where they are not.

The best thing to do when choosing a backup tool/strategy is to give some thought first to the *recovery* scenarios you need to support, and then design methods and choose tools to support those scenarios.

On Mon, Jul 20, 2015 at 8:31 PM, Andrew Kerber <andrew.kerber_at_gmail.com> wrote:

> Well, a VM is just a couple of data files. You should be able to back it
> up with some standard backup tools.
>
> Sent from my iPad
>
> On Jul 20, 2015, at 5:51 PM, Kenneth Naim <kennethnaim_at_gmail.com> wrote:
>
> Yes, there are many customizations, and I’d like the OS backed just like a
> physical server. The hyper-v snapshots are good, but the server seems to
> hang during the backup of the snapshots. I’m not involved with the OS but
> was asked to recommend a utility or product to back up the linux system.
> The OS group is primarily a Windows based team. Any suggestions on a more
> user friendly alrternative than dd would be appreciated.
>
>
>
> Thanks,
>
> Ken
>
>
>
>
>
>
>
> *From:* MARK BRINSMEAD [mailto:mark.brinsmead_at_gmail.com
> <mark.brinsmead_at_gmail.com>]
> *Sent:* Monday, July 20, 2015 6:34 PM
> *To:* Andrew Kerber <andrew.kerber_at_gmail.com>
> *Cc:* kennethnaim_at_gmail.com; <oracle-l_at_freelists.org> <
> oracle-l_at_freelists.org>
> *Subject:* Re: Backup OEL Virtual Machine
>
>
>
> Hmmm. I'm not so sure that *no* backup is needed. Even if the VMs are
> based on a template, they are probably customized at least somewhat, so
> you'll probably want backups if you want to restore from a failure quickly.
>
> (My goal for backup/recovery is to expend as close as possible to *no*
> thought at recovery time. In this case, you would not want to be caught at
> recovery time scratching your head and wondering what sort of
> customizations need to be applied to your "template" in order to make the
> database open.)
>
>
>
> Depending on the VM technology, you might be able to make snapshots
> (exclude the disks managed by ASM, if you can). If the VM snapshot
> technology is really good, these might be very efficient on storage and
> other resources. Failing that, you should think probably about backing up
> the Linux filesystems exactly the same way you would a physical server.
>
> Yeah, backing up the filesystems on your VMs is going to consume some
> storage.
>
> Yeah, a lot of the data you're backing up is probably cloned from a
> template, so the backup might SEEM wasteful.
>
> But when those backups save you maybe 1 or 2 hours of effort (per virtual
> machine) at recovery time, you're likely to find it was worthwhile.
>
>
>
> On Mon, Jul 20, 2015 at 6:13 PM, Andrew Kerber <andrew.kerber_at_gmail.com>
> wrote:
>
> You probably don't need to if they are created from a template. Re
> creating them is fairly easy.
>
> Sent from my iPad
>
>
> On Jul 20, 2015, at 4:58 PM, Kenneth Naim <kennethnaim_at_gmail.com> wrote:
>
> Dear List,
>
> How do recommend backing up several OEL VM’s that house databases sitting
> on ASM. The databases themselves are already backed up to a HP StoreOnce
> device using the StoreOnce client and RMAN but I am concerned about the
> actual VM.
>
>
>
> Thanks,
>
> Ken
>
>
>
>
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jul 21 2015 - 19:05:46 CEST

Original text of this message