Hi, 07.11.2007 19:12,, Hydro Meteor wrote:: > > On Nov 7, 2007 1:26 AM, Arno Lehmann <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hello, > > 07.11.2007 12:17,, Hydro Meteor wrote:: > > Hi all, > > > > I just recently set up a migration resources in my Director > > configuration file to migrate from File (hard drive) to DVD. The > simple > > test I tried worked fine (the DVD+RW was written to just perfectly). > > Good to hear - I'm planning a similar (test) setup here :-) > > > Credit goes to Richard Mortimer who had suggested this strategy in an > off-list email! > > > > > The Bacula User's Guide states: > > > > As part of this process, *the File catalog records associated > with > > the first backup job are purged*. In other words, Migration moves > > Bacula Job data from one Volume to another by reading the Job > data > > from the Volume it is stored on, writing it to a different > Volume in > > a different Pool, and then purging the database records for the > > first Job. > > > > > > Strangely, my original backup job (of the File on the hard drive) was > > not purged. Is not the purge supposed to take place once the > migration > > has succeeded (e.g., after the DVD was successfully written to)? > > Note the difference between File records and Job records - the File > records should be purged, the Job records remain in the catalog. At > least that's how I read the above manual paragraph. > > > I > > wonder why mine simple test situation indicated no purging took > place? > > Have you actually checked for the File records, or only the Job > records? > > > Hi Arno, > > I use the very nice Bacuview program to display the contents of the > Catalog. It shows all jobs saved in the Catalog and indeed you are > right, the Job records are not purged. But, interestingly enough, > Bacuview also gives me a view of the "media" records which has a table > that looks like this:
Well, that table still doesn't hold any information about the file records :-) > > * Name Slot Status Jobs Bytes Expires Retention > Pool Name Pool Type Media * > > So, the file that was original saved (which should be purged) has the > name of "filetest" and it still exists in the Catalog (not purged), as in: > > Name: filetest1 > Slot: - > Status: Used > Jobs: 1 > Bytes: 54.3 MB > Expires: 2008-11-06 > Retention: 365 days > Pool Name: thefullPool > Pool Type: Backup > Media: HardDisc This is a volume file. You need to check what the catalog knows about its contents. I don't use bacuview, but in bconsole, there is a query for this. I suspect you'll find the original job is still known to be stored on this volume, the job will be marked as being migrated (status "M"). You will not find files associated with that original job in the catalog anymore - these have been purged. Only the files, neither the Job record itself nor the JobMedia records. > Note that the Jobs field is not the same as the JobID when presented by > Bacuview (there are separate views for the Jobs IDs). > > Maybe the file (in the example above named filetest1) has not been > purged because its retention is set for one year and therefore in a > situation whereby teh retention is set to some value, it overrides the > ability of the migration job to purge it from the Catalog? How all the retention periods work together in Bacula is described in the manual. I understand that a volume that has no more jobs on it, even if in its retention period, should get recycled. Most important is that recycling and purging only happen when actually needed. > Also, the actual file on the hard drive where it is saved (the archive) > also still exists and was not deleted (I presume then that migration > merely copies the archive but does not delete the original archive > itself). This isn't a big deal because the original archive copy can be > deleted later. The volume file exists and is neither deleted and truncated... yes. That's how Bacula works. > > By the way, the file "filetest1" was successfully migrated to "dvdtest1" > and an additional record shows up for the same table courtesy of Bacuview: There is not way to migrate files using Bacula. You can only migrate Jobs (as far as I know). You can't even migrate volumes. I suspect we've got a problem with the terminology, too :-) > Name: dvdtest1 > Slot: - > Status: Append > Jobs: 1 > Bytes: 54.3 MB > Expires: 2008-11-06 > Retention: 365 days > Pool Name: DVDFullPool > Pool Type: Backup > Media: DVD This is volume information. > > If I understand what the User's Guide is saying, in theory then, using > the above examples, "filetest1" meta data should be entirely purged from > the Catalog as it is in essence deprecated in favor of "dvdtest1", true? No. Only the file entries in the catalog regarding the migrated jobs file be purged. Neither the volume information nor the job information, and also not (I think) the JobMedia records. These are quite different things. > What if there is a bug or some problem in getting the Catalog to purge > the deprecated file meta data (let's say for example that perhaps file > retention length does not in fact override migration's ability to purge > and there is some other unknown reason as to why it is not purged even > though the User's Guide says it should be)? In such a case the purging > could and should be done manually true? For example, the original file > on the hard drive and the clone of the file on the DVD could have their > SHA1 checksums computed and compared. If the checksums match, then it > would be safe to both delete the original file on the hard drive and > delete its catalog meta data ( e.g., on the Bacula Console run a delete > --> Volume on the MediaID or the Volume name of the deprecated original > volume)? I suppose this is somewhat of an obvious question but migration > seems to be an interesting little animal with some new challenges. I think some of your worries come from not exactly understanding what information to expect in the catalog. Volume information stays in the catalog as long as you don't delete the volume - not the volume file, the DVD, or the tape, but from the catalog: 'delete volume=xxx'. Job records are removed when pruning happens. They are updated on Migration. JobMedia records are automatically handled. In essence, they are removed when their corresponding jobs are removed. File records are removed when a job's file entries are purged. This can be triggered by several events: The Job being purged, the volume being purged, or the jobs file retention period being over during a pruning run. If there are bugs in Bacula, that might break, true. In such a case, you wouldn't trust manual workarounds, because you wouldn't believe that you can do manually what Bacula should do automatically... If you're worried about disk space consumption of your volume files on disk, just make sure they are recycled in time. And limit their pools size. As far as I know, migration does not leave volumes unusable, and it does not unnecessarily clutter your catalog with data. Arno > Cheers, > > -H > > > > Arno > > > Thanks for any suggestions, > > > > -H > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a > browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Bacula-users mailing list > > Bacula-users@lists.sourceforge.net > <mailto:Bacula-users@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/bacula-users > > -- > Arno Lehmann > IT-Service Lehmann > www.its-lehmann.de <http://www.its-lehmann.de> > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > <mailto:Bacula-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bacula-users > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
