Thank you for your insights, Josh, you've given me some points to consider.
It would seem that for my intended purpose (restoration of entire VMs) LVM
snapshots are better suited. What I'm wondering is whether an in-VM setup
would also work for restoring virtual machines. The scenario I envision is
as follows: I'm going to do full backups of VMs (including all possible
configuration files, but excluding /dev, /proc, /mnt, /run, /sys). This
way, if a VM fails entirely and is unrecoverable otherwise, I can create a
new instance from scratch, then install bacula-fd on it, apply the original
config and restore the last full backup. This procedure should effectively
give me a clone of the original VM (not a clone in strict sense,
obviously). I have tried that on a test machine and it worked OK but,
inexperienced as I am with Bacula, I might be missing some quirks here.
Does it seem like a reasonable plan or am I going to paint myself into a
corner with this one?
Best regards,
Dawid Piotrowski
On 5 May 2014 18:44, Josh Fisher <jfis...@pvct.com> wrote:
>
> On 5/5/2014 10:44 AM, Dawid Piotrowski wrote:
>
>> Hello everyone
>>
>> I am preparing to implement Bacula on one of the servers I look after,
>> but being new to the Bacula subject I would like to ask for some advisory
>> from users more experienced.
>>
>> The server I mean to run Bacula on is Debian Wheezy-based and serves as a
>> host to several LVM-based Xen virtual machines running Wheezy as well. Some
>> of the VMs are database servers (mainly PostgreSQL). The intended Bacula
>> version is 5.2.6, available in Wheezy repositories.
>>
>> My first question concerns where it is more advisable to place Bacula
>> daemons: on the host system (and back up using LVM snapshots) or in the
>> virtual machines themselves? I guess it's easier to ensure data consistency
>> using LVM snapshots but I am afraid it would be much harder to restore the
>> machine in this way so I am inclined to install Bacula in the VMs. However,
>> wisdom comes from experience, so I ask you, the more seasoned users: which
>> of the ways is less likely to give me headaches and what are possible
>> 'gotchas' in each one? My intended use of Bacula is being able to restore a
>> failed VM back up quickly in case of a disaster, rather than restoring
>> single files. Any recommendations would be more than welcome.
>>
>
> Keep in mind that creating a LVM snapshot of an active filesystem is never
> a valid strategy. For example, DB tables must be locked while the LVM
> snapshot is created. It only takes a brief time to create the snapshot, but
> the VM must somehow be made quiescent while the snapshot is created. The
> only safe way I'm aware of is to pause the VM, create the snapshot, then
> resume the VM. Once created, the snapshot will have to store copies of
> modified blocks for as long as it lives, (ie. until it is backed up with
> Bacula). This means you must make sure volume groups have sufficient
> unallocated space for the needed snapshots. Nevertheless, Bacula jobs can
> be configured to run scripts before and after the backup so the LVM
> snapshot creation can be automated.
>
> That said, both methods are useful in different ways. LVM snapshots are
> great for disaster recovery or anything where restore can be an
> all-or-nothing process. On the other hand, for a file server VM where there
> is a need to restore that single file that a user accidentally deleted, LVM
> snapshots require more admin intervention. After restoring the snapshot it
> has to be mounted and the requested file found and somehow copied over to
> the VM. With bacula-fd running on the VM, restoring a subset of
> files/directories is easier and more fire-and-forget, because all that need
> be done is start the restore from the Bacula console.
>
> I recommend installing bacula-fd on file server VMs and using LVM
> snapshots for other VMs.
>
>
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
