Bacula-users

Re: [Bacula-users] Out of virtual tapes

2015-08-24 17:36:22
Subject: Re: [Bacula-users] Out of virtual tapes
From: Ana Emília M. Arruda <emiliaarruda AT gmail DOT com>
To: Radosław Korzeniewski <radoslaw AT korzeniewski DOT net>
Date: Mon, 24 Aug 2015 18:31:46 -0300
Hello Radoslaw,

On Mon, Aug 24, 2015 at 12:12 PM, Radosław Korzeniewski <radoslaw AT korzeniewski DOT net> wrote:
Hello,

2015-08-14 15:03 GMT+02:00 Ana Emília M. Arruda <emiliaarruda AT gmail DOT com>:
Hello Radoslow,

I was talking about the configurations of the bacula user that originated this thread. And I based my opinion on his pool configuration and list media output.


Well, in my very humble opinion there is no any evidence that RAT or Dimitri is making Full everyday.
 
I agree with you that some files are always backed up regardless of whether or not you are using a full backup job. And this is the case of virtual machine disk images.

You can always use a Delta plugin, Bacula GED(tm) or for VMware a Bacula vSphere plugin to get an block level Incremental backup of virtual machine images. You can save a lot of space in your archive. Delta and VSP is also working with tapes.

​We have XenServer virtual machines. AFAIK even the enterprise version do not have this feature yet.
 

In this case, IMHO there is a trade-off. Do I have enough space for keeping a 1 year retention backups of all my disk images?

Using above techniques you can have enough space for that. :)
 
Is this really necessary for me?

Depends. Do you ever need to restore something older that 1 week ago? Do you have any regulatory requirements (i.e. in my country there is a requirement for financial data to be available for 5 years), etc

​Yes we have. Not virtual machine disks. We have all our enterprise data backed up to reach 5 years retention. But using differential daily backups.
 
.

I have seen solutions that have a weekly or monthly full backups for VM disk images and daily backup for the data partitions of the virtual machines that are susceptible of changes dieting the week/month.

Sounds to me like a tricky to manage.

​Most of our virtual machines do not need frequently changes (remembering that data - log and conf files - is regularly backed up). We have upgrade plans and try to implement them immediatly after a regular full backup.

 
Also, the most cases I had seen that needs a
Virtual machine disk image restore are:

1) disaster recover: in this case, the last backup is what we need. Having this backup in more than one place is preferable than having later ones.

Right. Then you can use a job replication (SD->SD Copy Jobs) and techniques mentioned above for optimal performance.

​yes :)​
 
 
2) updates and/or upgrades in the virtual machine configuration do not work: in this case we need a backup immediately before the changes were made. In this case we can take care of always having a full backup before doing any software changes in the virtual machine.

I do not understand what you mean. Sorry.

​I mean that if an update and/or upgrade of any of your virtual machine software (OS, app, etc.) do not work, you will need to restore from a backup immediatly​ before the changes were made. This could be achieved restoring the last full virtual machine backup + the last full/incr/diff data backup (logs, cfg, etc.).
 

Finally, there is a large number of situations and in some of them maybe it could be necessary to have daily full backups. IMHO if we can avoid this, we can save space destined for backups.

Yes. I always perform a full backups daily for Bacula config and database dump only. Simpler DR for Bacula itself. For every other Job I always make Full+Incremental.

​I think we do the same :)​

Best regards,
Ana
 

best regards
--
Radosław Korzeniewski
radoslaw AT korzeniewski DOT net

------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
<Prev in Thread] Current Thread [Next in Thread>