Re: Backup OEL Virtual Machine
Date: Tue, 21 Jul 2015 14:37:17 -0400
Message-ID: <CAAaXtLBXSMSDOGs6xMTqNtHr5W73=Gfjd2ZjpfOzaw6iqCg5qw_at_mail.gmail.com>
This is often true. And where it is, hypervisor "snapshots" are probably going to be your best bet, especially if they are smart enough to de-dupe blocks that remain unchanged from your "template". But remember that recovery is still "all or nothing", so you may have to take some significant downtime just to restore a damaged crontab.
If you arrange separate per-file backups for the things that you *expect *to change relatively frequently (crontabs, /etc/oratab, etc.), snapshots could well be good enough.
Alternatively, an "incremental" filesystem-level backup is only going to backup the files that change, anyway. Would there be any harm in running an incremental backup once a day or once a week on a filesystem where almost nothing changes anyway?
All I am suggesting here is that, like anywhere else, one should first give thought to the *recovery* requirements, and then choose the backup solution that best fits them.
There is no such thing as a "one size fits all" backup solution". Anybody who tells you differently is probably trying to sell you something. ;-) [Apologies to William Goldman.]
On Tue, Jul 21, 2015 at 1:29 PM, Andrew Kerber <andrew.kerber_at_gmail.com> wrote:
> You typically don't make changes to a DB server all that frequently, on
> anything outside the database itself that is. If you do, you aren't doing
> it right. Quarterly patching, and the occasional crontab or shell script
> change should be about it. It should be easy enough to schedule something
> on a quarterly interval without problems.
>
> Sent from my iPad
>
> On Jul 21, 2015, at 12:05 PM, MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
> wrote:
>
> 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-lReceived on Tue Jul 21 2015 - 20:37:17 CEST