> Defining and figuring out what storage device is going to be used has > become a > bit too complicated in version 1.39.x. This is mainly due to the fact > that > we have two different storage devices for each job and three possible > places > to specify them:
My 2 cents worth: This can be simplified dramatically by specifying the Storage resource only in the Pool definition, and then specifying only the Pool in all other places. Since (IMHO) pools are highly unlikely to span multiple SDs, identifying what SD to use is selectable from the devices available in the Storage resource associated with the pool. Some notes below: > Migration job: > read storage: job storage resource Shouldn't the migration job always be using the Pool resource being migrated and feeding to the NextPool, or overriding the NextPool resource, not the storage resource? For migration, we're looking at volumes in pools, not individual volumes (other than the case where we have deliberately limited the selection criteria to a specific volume within a pool via the selection keyword), so there should be no reason to specify individual devices for migration jobs. > read storage: pool storage resource Correct. > read storage: run override resource See above. Migration is about pools, not devices. If you need to migrate to volumes that are not in a pool then you set up a temporary pool and draw it's volumes from the scratch pool. > read storage: command line??? Not sure what you mean by this. > write storage: pool next pool storage resource > (yea, try to figure out the above in C it is > job->pool->next_pool->storage Correct as I understand the implementation. See comments above. > Backup Job: > write storage: job storage resource See above for discussion of pools. If pools drive the selection of volumes, the pool definition will clearly define what SD should be used, unambiguously and consistently across all actions in Bacula. > write storage: pool storage resource Ditto. > write storage: run override resource Ditto. > write storage: command line??? Not sure again. > Restore Job: > read storage: who knows, probably the same as > Migration. To be checked. In a normal case, the pool definition of the pool containing the volume should determine the SD to use. In the nasty case of full disaster, you could temporarily override the pool storage resource from the command line, but that (in my mind) would be a situation where you are clearly out of the normal parameters, and are doing it consciously. See comments above wrt to Migration. The same cases exist; migration just makes this problem more visible. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
