[CentOS] [OT] Bacula offsite replication

Wed Jul 8 07:08:27 UTC 2020
Alessandro Baggi <alessandro.baggi at gmail.com>

Il 02/07/20 16:39, Valeri Galtsev ha scritto:
> On 2020-07-02 08:28, Alessandro Baggi wrote:
>> Il 02/07/20 15:02, Valeri Galtsev ha scritto:
>>> On 7/2/20 3:22 AM, Alessandro Baggi wrote:
>>>> Il 01/07/20 17:13, Leroy Tennison ha scritto:
>>>>> I realize this shouldn't happen, the file is a tgz and isn't being 
>>>>> modified while being transmitted.  This has happened maybe three 
>>>>> times this year and unfortunately I've just had to deal with it 
>>>>> rather than invest the time to do the research.
>>>>> Harriscomputer
>>>>> Leroy Tennison
>>>>> Network Information/Cyber Security Sp
>>>> Hi Leroy,
>>>> I think that in my case I could not use a tgz archive. I'm speaking 
>>>> about full backups that reach 600/700GiB, compressing them and then 
>>>> rsync them could take so much time that it will be useless.
>>> unless you use tape (of that high capacity), it is advantageous to 
>>> restrict volume size to, say, 50GB. Then when you restore, search 
>>> for specific files will be faster. And it will help your backup 
>>> volumes transfers as well.
>>> Valeri
>> Hi Valeri,
>> thank you for your suggestion.
>> Is bacula the right backup system when I need to replicate data 
>> offsite? There are other backup solution that simplify this process?
> Bacula is great enterprise level open source backup system. I switched 
> to its fork bareos at some point; I use bacula/bareos for at least a 
> decade. And with this your extra requirement I still would stay with 
> bareos (or bacula).
> If I were to have two sets of backup: on site and off site, I would 
> just set up separate bacula/bareos director and storage daemon(s) off 
> site. Add to FDs (file daemons) extra instances of director - offsite 
> one with different passwords for the sake of security. Then there will 
> be a set of everything off site, not only a set of volumes. Of course, 
> if you only have a set of volumes, but everything else has evaporated, 
> you still will be able to restore everything, including database 
> records by scanning set of volumes. Which will take forever. I would 
> alternate dates of backups in offsite/onsite schedules, or define 
> times of backups so that they do not overlap.
> Another good news of this vs just rsyncing volumes is: bacula/bareos 
> verifies checksum of every backed up file after receiving it. This 
> will ensure consistency of files in remote volumes, for rsync you will 
> have to at least verify checksum of each volume transferred to 
> destination (unless I miss my wits and rsync does verify checksums of 
> files transferred, I just re-read rsync man and don't see verification 
> - hopefully rsync expert will chime in and correct me if I'm wrong 
> about rsync).
> Anyway, that is what I would do.
> Valeri
Hi Valeri,

I'm in late but thank you for your suggestion.