On 6/29/2011 11:38 AM, Mike Hobbs wrote: > On 06/28/2011 04:38 PM, Josh Fisher wrote: >> It isn't necessary. jbod1-drive-1, jbod1-drive-2, etc. are virtual >> drives. The ArchiveDevice path in each virtual drive contains a symlink. >> The symlink is created by vchanger to point to the folder containing the >> volume file that is to be used. Any of the virtual drives may be >> "loaded" with a volume from any of the "magazines" (ie physical drives). > > Ah, ok... so all these months I have been looking at this the wrong > way! I didn't realize bacula was telling me what "virtual drive" it > was using, I thought it was telling me what drive bacula "thinks" it > was writing to! Thank you for clearing that up for me! So, if I > understand what you are saying, I should leave the "Autochanger" > config in my bacula-sd file, and I can remove the 16 "Device" entries > in my SD file?
Well, not all of them. You need to define at least one, and you probably want several. It depends on the level of concurrency used, which depends on the maximum write throughput of the JBOD device, as well as the maximum throughput of the network connecting the clients, etc. In other words, how many jobs can you run concurrently before hitting the throughput bottleneck, whatever that bottleneck may be. It will require some testing to figure that out. >> It is possible for all 16 of your virtual drives to be simultaneously >> writing to different volume files on the same physical drive. > >> What this is telling you is that you are not running jobs >> concurrently, so they are all using SD device jbod1-drive-1. > > I most definitely want to run jobs concurrently! Once in production I > will be backing up a 200-300 machines! I thought I had configured > bacula correctly for this as I am pretty sure I saw multiple jobs > running at the same time.. Maybe they were, but they were using the > same "virtual disk"? How do I get bacula to write data using more > than one virtual drive? I have all my config files set to 20 for > concurrent jobs, but evidently the jobs are all using the same VD and > not multiple VD's. What am I missing? If two concurrent jobs both select the same volume, they will both write to the same volume simultaneously, interleaving their data records. Since a volume can only be loaded in one drive, they will both necessarily use the same virtual drive. Interleaved volumes cause slower restores, since Bacula has to skip around to find the records for the job being restored. Though that is less of a problem on disk than on tape, I still prefer non-interleaved volumes. This is accomplished by setting MaximumConcurrentJobs=1 in each of the "Device" definitions in bacula-sd.conf. This can present a problem, in that if two jobs select the same volume, then they cannot run concurrently. MaximumConcurrentJobs=1 in the SD Device definition allows only one job at a time to be able to write to a particular volume. By default, Bacula will select a volume that is already in a drive in preference to a volume not in a drive. For concurrent jobs writing to the same pool, this means they will always select the same volume. Thus if you set MaximumConcurrentJobs=1 in the SD Device, then it will not be possible to run concurrent jobs that write to the same pool, because the concurrent jobs will select the same volume, which can only be written to by one job at a time, forcing them to be serialized. To get around the default behavior, set PreferMountedVolumes=no in the Job definition of the jobs that will both run concurrently AND write to the same pool. This will cause the opposite behavior. Bacula will prefer selecting a volume that is NOT already in use in a drive, effectively meaning it will select a volume that is not already in use, loading it into another drive if necessary. This way, jobs writing to the same pool can run concurrently, each writing to a different volume, ensuring that volume data is not interleaved. > > Thank you for your help and a great explanation of what's going on! > > mike ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users