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@xxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxx
<mark.brinsmead@xxxxxxxxx>]
*Sent:* Monday, July 20, 2015 6:34 PM
*To:* Andrew Kerber <andrew.kerber@xxxxxxxxx>
*Cc:* kennethnaim@xxxxxxxxx; <oracle-l@xxxxxxxxxxxxx> <
oracle-l@xxxxxxxxxxxxx>
*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@xxxxxxxxx>
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@xxxxxxxxx> 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
