Backup Suggestion On C7

Home » CentOS » Backup Suggestion On C7
CentOS 6 Comments

Hi list, I’ve solved my problem.

I’ve understood some concepts.

I’ve defined bacula-sd multiple devices with different Media Type and configured different storage directives in director.


6 thoughts on - Backup Suggestion On C7

  • I’m sure some people will tell me I’m doing it wrong but I always just use rsync for backups, automated in cron.

    I may be doing it wrong but it always works.

  • Hi list, I’m building a backup server for 3 hosts (1 workstation, 2 server). I
    will use bacula to perform backups. The backup is performed on disks (2
    x 3TB on mdraid mirror) and for each hosts I’ve created a logical volume with related size.

    This 3 hosts have different data size with different disk change rate. Each host must have a limited sized resource and a reserved space. If a server needs more space to perform backup, It must be enabled and provisioned.

    My first solution was put each host pools on different logical volumes, like:

    host1 -> lv1
    host2 -> lv2
    host3 -> lv3

    and store pools/volumes on specified storage daemon that uses a specified device for each different hosts.

    host1 -> storage1 -> device_lv1
    host2 -> storage2 -> device_lv2
    host3 -> storage3 -> device_lv3

    Unfortunately, I can’t define on bacula-sd.conf multiple storage definition but only multiple devices. To use different storage I must run 3 bacula-sd on same host (I can?), run a bacula-sd on a vm/host. Ah, I must use only one physical server.

    With one single machine and the current state I can’t use multiple storage daemons.

    There are other ways to store host volumes on different devices?

    My second solution was, use only one storage daemon (on the same host)
    with a single device LVM over mdraid, create pool for each hosts and limit the size for each volumes on related pool.


    Thanks in advance.

  • –AfKRCdRqDcR54SGW0CG2O8BxnJqcM07jk Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    I’m not a bacula expert, but have had 30+ years in the industry doing backups. I’m a little concerned about what you are planning. As I
    understand it you are going to be keeping just one copy of each machine on a disk attached to the server. This will help if you loose the running disks (though it is hardly backup in depth), but what happens if you loose the server due to fire, flood, electrical problems, theft or even plain old dropping it? In general you should aim for multiple backup copies; are you willing to bet the company’s future on one untried copy? You should ensure that the backup copies are held preferably off site, failing that in a separate building, or else in a secure fireproof strongbox.

    Start by assuming you come into work one day to find the building burnt out and collapsed. Now work out how to rebuild your system on new kit on another site and you’ll find that you define your backup needs.

    Regards, Martin


  • –6qee6Gr2vbrUdlOc0Ovtlqhi6hErmth6q Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    Mark has asked me to forward this to the list:

  • You’re doing it wrong. ;-)

    You’re not really doing it ”wrong”, it just depends on what your needs are. One drawback to using just rsync is, if a user deletes a file, then needs it back after the rsync was run again, the file may no longer be in your backups (similar if the user modified it and needs the original pre-mod file back). If you’re okay with that, then rsync is fine for your needs.

    rsnapshot uses rsync with hard links to be able to efficiently keep snapshots (not point-in-time snapshots, just whatever was present when rsync sync’d each file) on a periodic basis. bacula is a more sophisticated method for doing this efficiently across multiple hosts. LVM snapshots allow for a real point-in-time snapshot (which can then be backed up with your favorite tool).

    It always works until it doesn’t. This is unfortunately all too true when it comes to backups. It’s easier to inspect backups on disk than when they used to be done to tape, but it’s still good to verify them outside of your normal backup routine periodically.


  • Hi Martin, this is the off-site backup. Each server is backupped also in farm.

    Il 13/10/2016 22:24, J Martin Rushton ha scritto: