Accidentally replied directly. Sending to list this time. :)
On 2/11/22 01:54, [email protected] wrote: > Hello Bill!!! > > First of all, thank you so much for your nice email. Really mate, thank you > for your nice answer. You are welcome. Glad to help! >> *Totally agree. 5 or 10 minutes are enough for one volume but... imagine you >> have volumes of 5GB max and a job then starts >> as soon as the volume is available. Then that volume becomes full becose >> filling a 5GB volume is absolutely fast... then >> you see the commented effect. At least you see that effect in Bacula 5....* Two things here... First, I generally like to use 10GB volumes. That is just my personal preference. I think 5GB is a bit too small, and I see other liking 50GB and Kern Sibbald (Guess who he is :) once told me he likes 100GB volumes. It is really a matter of your environment mixed with some personal preferences. Second, I would strongly urge you to upgrade because your version v5.x is so old, and it is possible some of the things I recommended in my previous email might not even be available in that version. :) >> *You mean setting MaxVolumeBytes in the pool's config and just using this >> directive instead of a later update?. It seems so :) :) nice idea!!! Yes! Bacula, once configured to your environment and liking, will basically run in the background doing all the hard work for you. ;) >> You should set "MaximumVolumeBytes" in your Pool(s), then, as Bacula creates >> a volume or moves a volume into the pool the >> volume inherits this setting (and some others). >> *Nice idea really :) ... I didn't know this directive existed.... it allows >> me not to need the update command after label....* Yes! Another nice automation feature. >> *What you said in the last two paragraphs is just nice. Just nice!. Yes. I like the ScratchPool and RecyclePool features. They are very nice for the reasons that I wrote in my previous email. I have colleagues that don't like them, but we just disagree and laugh about it all the time. :) Of course, I am right and they are wrong about this. hehehe :) >> *Please, let me comment a couple of things. We are planning to backup our >> machines with consolidated virtualfull + >> incremental backups forever. If you plan to do this, and "forever" to you really means forever, then I would strongly recommend running Verify (Level=Data) jobs immediately after the Virtual Fulls and pay careful attention to the termination status of these Verify jobs. I am pretty sure that version 5.x does not have Verify jobs but this is just a guess at 22:30 on a Saturday night without even checking any change logs to be sure. :) Personally, I would not let "forever" mean more than about 6 months, but that is just me. But, with the Verify (Level=Data) jobs running immediately after, you should be safe I would say. Speaking of "monitoring the Verify jobs closely", if you do not know yet, I have written a Python script that will send you a nice HTML email with everything you might want to know about the jobs that have been recently run. It is meant to be triggered from a daily cron job so that you can get this email every morning to have a detailed status report on the previous night's jobs. The latest version can always be found here: https://github.com/waa/bacula Note, this script requires Python v 3.9 minimum, and a few extra Python modules also need to be installed. I cannot even be sure that it will work with Bacula v5.x as I have only used Bacula Enterprise 12.8.3 & 14.0.2, and Bacula Community 11.0.5 to do all the development and testing. If it works with Bacula v5.x please let me know, I know there have been quite a few db schema updates since v5.x, so it would be interesting if this were the case. Some of our machines take ages in being backed up and this way, as we use "Accurate" backups, >> we could avoid some load on that servers. * Yes, and be advised that Accurate mode is actually *required* for Virtual Full backup jobs. ;) >> *For that purpose, we have the incremental jobs pool and the virtual full >> jobs pool. Both of them share phisically the same >> directory because else, when Bacula needs to read a previous virtual full >> job terminated, it's not able to find curiously >> the virtual full jobs volumes in their own pool (the pool for volumes used >> in virtual full backups).* This is OK, but not necessary. Consider that you can add as many virtual disk autochangers with as many drive devices as you like. So, you can have one SD with (for example) two autochangers, and then you can run the Virtual Full jobs from the first set of full/inc/diff pools into a different pool "Virtual Full" with different retention periods, and the Virtual Full backups can even be written to different disk/cloud/tape locations. For my disk autochangers, I like to start with a minimum of 10 drive devices no matter the environment because it gives me a lot of freedom to expand without the need to restart the SD. Additionally, I usually add 2 (or more) 'read-only' drive devices in the autochangers too so that there should always be a drive available to read from for Verify and/or Copy and Migration jobs. >> *You said that for having a Full pool and a diff pool and a inc pool, using >> a scratch and a recycle pool works nice. >> *Should it work too, in our progressive virtual full scenario?. Absolutely. This configuration that I like with those options has nothing to do with the ideal of Virutal Fulls, but they will work together. Additionally, to be 100% sure that Full/Inc/Diff Jobs go into the correct Full/Inc/Diff pools, I love the four Job features called "FullBackupPool", "IncrementalBackupPool", "DifferentialBackupPool", and "VirtualFullBackupPool" The Job will still need a "Pool=" set to satisfy the configuration parser, but it will be ignored because whatever the level of the job is, it will be one of those, and one these four settings will always override the "Pool=". This is really nice to prevent mistakes when a job has "Level = Incremental" (for example) and someone manually runs a Full and the wrong pool might be used. :) Oh and make sure you understand the differences of "Virtual Full" vs "Progressive Virtual Full" so you do not loose access to older backup data if you use PVF instead of VF. ;) >> *I'm using this version, but I don't really need that stop feature if I can >> use a scratch and a recycle pool as you stated >> (we will see later how to restrict each customer's used backup bytes)*. Exactly! >> And finally, you can set a "LabelFormat" in your disk volume pools (try to >> keep it simple), and set "LabelMedia = yes" in >> your disk devices and Bacula will do this entire job for you automatically. >> Just make sure to also set MaximumVolumes to some >> sensible number so that you do not fill your disk partition(s) to capacity. >> ;) >> *Higely nice advice too mate :) :) :)* Yes! If you configure these things that I mentioned in my last reply, you will have a lot more free time to do things you enjoy rather than babysitting your Backups! :) >> Hope some of this helps. :) >> *Helps, are you joking??. Is what I was looking for !!!! * :) Glad I could help! >> *Can I transfer you some € through paypal for inviting you a coffee or beer?. :) No one has ever asked! It is funny you should ask today because I struggled over deciding whether or not to put my Venmo account into the comments at the top of that email reporting script I mentioned above, but I have put quite a bit of time into it and I think it is in a (pretty close to) full-featured state at this time, so I finally did. Maybe I will put my Paypal in there too. Who knows, maybe I will be able to retire soon if I do. lol :D :D :D >> *Thanks a lot really again. Please keep my email for any help or thing you >> could need. I work at an ISP and if you have >> sometime, some kind of new doubt and I don't really know how to answer, I >> will ask it internally for you and give you an >> answer.* Will do! Thank you for the detailed reply and kind words. Glad I could help. >> *Cheers Bill!* Cheers! Bill -- Bill Arlofski [email protected] _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
