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.