Re: [Bacula-users] Restoring from a copy job
On Wednesday 2021-12-01 09:11:43 Eric Bollengier via Bacula-users wrote: > Hello, > > On 11/30/21 22:31, Phil Stracchino wrote: > > On 11/30/21 14:54, Josip Deanovic wrote: > >> On Tuesday 2021-11-30 12:07:37 Phil Stracchino wrote: > >>> The question then ceases to be "I have twenty possible volumes from > >>> which your restore could be performed, which five of the twenty > >>> volumes > >>> do you want to use?", and instead becomes, "I have four possible > >>> SOURCES to perform this restore from, please pick *one restore > >>> source*.">> > >> The restore command of the bconsole tool already has the "pool" > >> command > >> line argument which could be used for volume selection. > >> > >> In my case with Bacula 9.6.7 it didn't work with copy jobs. It would > >> be > >> nice to make it work with newer Bacula versions (e.g. 11.x). > >> > >> Eric mentioned that MediaType might potentially be used in the > >> selection algorithm. I am not sure if this is necessary if we get a > >> working "pool=" argument. > > > > Indeed, and Pool is probably a better discriminator in this case than > > MediaType. In my case, the two relevant pools for Full backups are > > Full-Disk and Full-Archive, and both are Media Type = File. In any > > random hypothetical environment with copy jobs, I would expect it to > > be far more likely that Copy jobs will be in a different Pool than > > that they will have a different media type. > I don't know, personally, I'm using different pools to have different > retention, so, we have a simple case where all jobs are in one pool > (from Full to the last Incr), but it's a corner case as well. > > We can add a pool= or a mediatype= kind of keyword in the restore > command line, however, it's far from being very friendly as what we can > find in Baculum for example. I will think about it and your ideas are > welcome. But the command line parameter "pool=" already exists in bconsole tool. It just doesn't work in my 9.6.7 setup. Not sure if it would work with 11.x version of Bacula. Regards! -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
Hello, On 11/30/21 22:31, Phil Stracchino wrote: On 11/30/21 14:54, Josip Deanovic wrote: On Tuesday 2021-11-30 12:07:37 Phil Stracchino wrote: The question then ceases to be "I have twenty possible volumes from which your restore could be performed, which five of the twenty volumes do you want to use?", and instead becomes, "I have four possible SOURCES to perform this restore from, please pick *one restore source*." The restore command of the bconsole tool already has the "pool" command line argument which could be used for volume selection. In my case with Bacula 9.6.7 it didn't work with copy jobs. It would be nice to make it work with newer Bacula versions (e.g. 11.x). Eric mentioned that MediaType might potentially be used in the selection algorithm. I am not sure if this is necessary if we get a working "pool=" argument. Indeed, and Pool is probably a better discriminator in this case than MediaType. In my case, the two relevant pools for Full backups are Full-Disk and Full-Archive, and both are Media Type = File. In any random hypothetical environment with copy jobs, I would expect it to be far more likely that Copy jobs will be in a different Pool than that they will have a different media type. I don't know, personally, I'm using different pools to have different retention, so, we have a simple case where all jobs are in one pool (from Full to the last Incr), but it's a corner case as well. We can add a pool= or a mediatype= kind of keyword in the restore command line, however, it's far from being very friendly as what we can find in Baculum for example. I will think about it and your ideas are welcome. Thanks, Best Regards, Eric ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
On 11/30/21 14:54, Josip Deanovic wrote: On Tuesday 2021-11-30 12:07:37 Phil Stracchino wrote: The question then ceases to be "I have twenty possible volumes from which your restore could be performed, which five of the twenty volumes do you want to use?", and instead becomes, "I have four possible SOURCES to perform this restore from, please pick *one restore source*." The restore command of the bconsole tool already has the "pool" command line argument which could be used for volume selection. In my case with Bacula 9.6.7 it didn't work with copy jobs. It would be nice to make it work with newer Bacula versions (e.g. 11.x). Eric mentioned that MediaType might potentially be used in the selection algorithm. I am not sure if this is necessary if we get a working "pool=" argument. Indeed, and Pool is probably a better discriminator in this case than MediaType. In my case, the two relevant pools for Full backups are Full-Disk and Full-Archive, and both are Media Type = File. In any random hypothetical environment with copy jobs, I would expect it to be far more likely that Copy jobs will be in a different Pool than that they will have a different media type. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
On Tuesday 2021-11-30 12:07:37 Phil Stracchino wrote: > > However, in a case where there are two or more complete sets of jobs on > different pools or devices, both containing all of the jobs necessary to > perform the desired restore, it SEEMS that it should be conceptually > simple to list the jobs and sources and allow the user/administrator to > select a restore SOURCE, then automatically select the volumes and jobs > required to perform the restore from that source. This seems much > simpler than trying to choose from all possible sets of jobs/volumes. > > The question then ceases to be "I have twenty possible volumes from > which your restore could be performed, which five of the twenty volumes > do you want to use?", and instead becomes, "I have four possible SOURCES > to perform this restore from, please pick *one restore source*." The restore command of the bconsole tool already has the "pool" command line argument which could be used for volume selection. In my case with Bacula 9.6.7 it didn't work with copy jobs. It would be nice to make it work with newer Bacula versions (e.g. 11.x). Eric mentioned that MediaType might potentially be used in the selection algorithm. I am not sure if this is necessary if we get a working "pool=" argument. -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
On 11/30/21 11:01, Bill Arlofski via Bacula-users wrote: On 11/30/21 01:38, Eric Bollengier wrote: Note, that it's also possible to have multiple copies of each job, on different kind of devices, and some jobs involved may not have copies. Now, if we can determine a selection algorithm (via MediaType?), we can probably implement it. Bconsole is not the best tool for advanced selection screens, however Baculum GUI has an excellent supports the copy job selection and can also display the different versions of a file, and let you restore the one you want for example. Yes, this is true, and something people (like me for example) often forget - A backup job may be copied many times, and to every different storage type - So making a guess which copy the user wants to restore from would be impossible. :) So, the workflow as I described in my follow-up replay last night currently is the right one and it makes more sense considering the multiple copies scenario. However, in a case where there are two or more complete sets of jobs on different pools or devices, both containing all of the jobs necessary to perform the desired restore, it SEEMS that it should be conceptually simple to list the jobs and sources and allow the user/administrator to select a restore SOURCE, then automatically select the volumes and jobs required to perform the restore from that source. This seems much simpler than trying to choose from all possible sets of jobs/volumes. The question then ceases to be "I have twenty possible volumes from which your restore could be performed, which five of the twenty volumes do you want to use?", and instead becomes, "I have four possible SOURCES to perform this restore from, please pick *one restore source*." -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
On 11/30/21 01:38, Eric Bollengier wrote: > Hello, > > On 11/30/21 04:52, Bill Arlofski via Bacula-users wrote: >> >> >> So far, so good... BUT it gets better because Bacula notices that I have >> copies of these five jobs! Excellent! >> >> So it prints: >> >> These JobIds have copies as follows: >> ++---+---+---+ >> | jobid | job | copyjobid | mediatype | >> ++---+---+---+ >> | 43,803 | Speedy.2021-11-29_03.15.00_39 |43,813 | Synology-File | >> | 43,777 | Speedy.2021-11-28_03.15.00_39 |43,788 | Synology-File | >> | 43,751 | Speedy.2021-11-27_03.15.00_39 |43,762 | Synology-File | >> | 43,725 | Speedy.2021-11-26_03.15.00_39 |43,736 | Synology-File | >> | 43,699 | Speedy.2021-11-25_03.15.00_08 |43,710 | Synology-File | >> ++---+---+---+ >> >> But then this is where the breakdown is... >> >> Bacula ignores those five copy jobids, and reports that it is building the >> restore tree from the original backups jobids: >> >> You have selected the following JobIds: 43699,43725,43751,43777,43803 >> >> Building directory tree for JobId(s) 43699,43725,43751,43777,43803 ... >> + >> 554,180 files inserted into the tree. >> >> >> So, I think I need to report this. (or amend the Mantis if one exists :) >> > > The command prints the alternative to the different jobs, I don't think it can > choose for you, here in this example, we have 2^5 different possibilities to > restore the files, I'm not sure Bacula can guess automatically which one do > you want in the mix. > > The basic idea is that the original job is usually stored on fast and > available > disks, the copy is more likely stored on tape or cloud kind of slow access > device. > > When the original job is purged (usually you have a smaller retention), then > the > copy job is "promoted", and the next restore command will select it > automatically. > > Note, that it's also possible to have multiple copies of each job, on > different > kind of devices, and some jobs involved may not have copies. Now, if we can > determine a selection algorithm (via MediaType?), we can probably implement > it. > > Bconsole is not the best tool for advanced selection screens, however Baculum > GUI has an excellent supports the copy job selection and can also display the > different versions of a file, and let you restore the one you want for > example. > > Best Regards, > Eric > Hello Eric! Thank you for the detailed reply. Yes, this is true, and something people (like me for example) often forget - A backup job may be copied many times, and to every different storage type - So making a guess which copy the user wants to restore from would be impossible. :) So, the workflow as I described in my follow-up replay last night currently is the right one and it makes more sense considering the multiple copies scenario. Best regards, Bill -- Bill Arlofski w...@protonmail.com ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
On Tuesday 2021-11-30 04:54:35 Bill Arlofski via Bacula-users wrote: > Hello Josip, > > I did a little research and found the old Mantis ticket I was referring > to... > > However, the result from the conversation with the developers was as > follows: > > > The "copies" option is doing only what is described in the manual: > 8< > If the keyword copies is present on the command line, Bacula > Enterprise will DISPLAY the list of all copies for selected jobs. > 8< > > So, if you actually you want to restore from the copies, you need to > cancel the restore at the point where the copy jobids are displayed, > then run the restore job again but instead of specifying the client and > fileset you can specify the copy jobids as follows: > > * restore jobid=1,2,3,4,5 (where 1,2,3,4,5 are the jobids of the copy > jobs) > > It is not the way I would expect or hope the 'copies' option would > function, but at least it is "functioning as documented"™ :) > > Hope this helps. :) Thank you Bill, it helped and restore from copy jobs from tape pool works without issues now when I am properly using it. I expected the "copies" argument to work exactly as the documentation stated: "display the list of all copies for selected jobs" but I missed and completely ignored the "copyjobid" column given in the list. I was steered in the wrong direction by the part of the documentation covering restore command line arguments which says: "- pool=pool-name - specify a Pool name to be used for selection of Volumes when specifying option 5 and 6 (restore current system, and restore current system before given date). This permits you to have several Pools, possibly one offsite, and to select the Pool to be used for restoring." That part with specifying pool (in my case tape1) doesn't work although I am using separate storage, device and media type for that specific pool. Maybe there is a bug regarding that because when I specify a pool, after I select option 5 and then client and its particular job, it immediately returns this output: "No Full backup before 2021-11-30 09:42:58 found." Thanks again, you helped a lot and I can confirm that restoring from copy jobs is working with Bacula 9.6.7 when jobid= is used with the values from the "copyjobid" column listed by "copies" argument. Regards! -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
On Tuesday 2021-11-30 08:51:40 Radosław Korzeniewski wrote: > Hello, > > wt., 30 lis 2021 o 06:01 Bill Arlofski via Bacula-users < > > bacula-users@lists.sourceforge.net> napisał(a): > > It is not the way I would expect or hope the 'copies' option would > > function, but at least it is "functioning as documented"™ :) > > The way my customers are using it is when "originals" are not available > for restore, then restore from copies works perfectly as expected. So, > when doing copy for offline, off-site storage, disaster recovery, long > term, low-cost storage, etc. etc. Yes. In my case I needed it to test the offsite storage, media and backup itself. While I was googling for the solution, I have found that people often misinterpret the documentation which says that Bacula will automatically promote copy jobs if the records about original jobs are purged from the catalog. It seems that people read the last part as: "if the original jobs are not available" which is not correct. Their records must be deleted from the database. > It is not perfect and does not cover all use cases you can imagine for > sure. But do the real work when required. I am fine with it as long there is a way to perform restore from copy jobs. I don't mind if it takes an extra step as long as it works. :-) Regards! -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
On Tuesday 2021-11-30 09:19:51 Marcin Haba wrote: > Hello Josip, > > Baculum supports restore from copy jobs. It is a function in the > restore wizard that default is enabled. So you can just select copy > jobs and restore from them all or selected files. This function is > available from Baculum version 9.6.0. > > If you prefer doing it using Bconsole, you can use Bvfs restore > commands for that. But please be careful with .bvfs_get_jobids command > in version lower than 11.0.3, because there was a bug in this command > with copy jobs: > > https://bugs.bacula.org/view.php?id=2500 > > Besides that it works well. Thank you for confirming it works on 9.6.x. I am currently not using Baculum but Bill helped me to find the solution. In short, the solution is: 1. use "restore copies" to get the list of IDs of copy jobs 2. use "jobid=copyjob1,copyjob2" to select the copy jobs listed in the copyjobid column Regards! -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
Hello, On 11/30/21 04:52, Bill Arlofski via Bacula-users wrote: So far, so good... BUT it gets better because Bacula notices that I have copies of these five jobs! Excellent! So it prints: These JobIds have copies as follows: ++---+---+---+ | jobid | job | copyjobid | mediatype | ++---+---+---+ | 43,803 | Speedy.2021-11-29_03.15.00_39 |43,813 | Synology-File | | 43,777 | Speedy.2021-11-28_03.15.00_39 |43,788 | Synology-File | | 43,751 | Speedy.2021-11-27_03.15.00_39 |43,762 | Synology-File | | 43,725 | Speedy.2021-11-26_03.15.00_39 |43,736 | Synology-File | | 43,699 | Speedy.2021-11-25_03.15.00_08 |43,710 | Synology-File | ++---+---+---+ But then this is where the breakdown is... Bacula ignores those five copy jobids, and reports that it is building the restore tree from the original backups jobids: You have selected the following JobIds: 43699,43725,43751,43777,43803 Building directory tree for JobId(s) 43699,43725,43751,43777,43803 ... + 554,180 files inserted into the tree. So, I think I need to report this. (or amend the Mantis if one exists :) The command prints the alternative to the different jobs, I don't think it can choose for you, here in this example, we have 2^5 different possibilities to restore the files, I'm not sure Bacula can guess automatically which one do you want in the mix. The basic idea is that the original job is usually stored on fast and available disks, the copy is more likely stored on tape or cloud kind of slow access device. When the original job is purged (usually you have a smaller retention), then the copy job is "promoted", and the next restore command will select it automatically. Note, that it's also possible to have multiple copies of each job, on different kind of devices, and some jobs involved may not have copies. Now, if we can determine a selection algorithm (via MediaType?), we can probably implement it. Bconsole is not the best tool for advanced selection screens, however Baculum GUI has an excellent supports the copy job selection and can also display the different versions of a file, and let you restore the one you want for example. Best Regards, Eric ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
Hello Josip, Baculum supports restore from copy jobs. It is a function in the restore wizard that default is enabled. So you can just select copy jobs and restore from them all or selected files. This function is available from Baculum version 9.6.0. If you prefer doing it using Bconsole, you can use Bvfs restore commands for that. But please be careful with .bvfs_get_jobids command in version lower than 11.0.3, because there was a bug in this command with copy jobs: https://bugs.bacula.org/view.php?id=2500 Besides that it works well. Best regards, Marcin Haba (gani) On Tue, 30 Nov 2021 at 08:54, Radosław Korzeniewski wrote: > > Hello, > > wt., 30 lis 2021 o 06:01 Bill Arlofski via Bacula-users > napisał(a): >> >> >> It is not the way I would expect or hope the 'copies' option would function, >> but at least it is "functioning as documented"™ :) > > > The way my customers are using it is when "originals" are not available for > restore, then restore from copies works perfectly as expected. > So, when doing copy for offline, off-site storage, disaster recovery, long > term, low-cost storage, etc. etc. > > It is not perfect and does not cover all use cases you can imagine for sure. > But do the real work when required. > > best regards > -- > Radosław Korzeniewski > rados...@korzeniewski.net > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- "Greater love hath no man than this, that a man lay down his life for his friends." Jesus Christ "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie za przyjaciół swoich." Jezus Chrystus ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
Hello, wt., 30 lis 2021 o 06:01 Bill Arlofski via Bacula-users < bacula-users@lists.sourceforge.net> napisał(a): > > It is not the way I would expect or hope the 'copies' option would > function, but at least it is "functioning as documented"™ :) > The way my customers are using it is when "originals" are not available for restore, then restore from copies works perfectly as expected. So, when doing copy for offline, off-site storage, disaster recovery, long term, low-cost storage, etc. etc. It is not perfect and does not cover all use cases you can imagine for sure. But do the real work when required. best regards -- Radosław Korzeniewski rados...@korzeniewski.net ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
Hello Josip, I did a little research and found the old Mantis ticket I was referring to... However, the result from the conversation with the developers was as follows: The "copies" option is doing only what is described in the manual: 8< If the keyword copies is present on the command line, Bacula Enterprise will DISPLAY the list of all copies for selected jobs. 8< So, if you actually you want to restore from the copies, you need to cancel the restore at the point where the copy jobids are displayed, then run the restore job again but instead of specifying the client and fileset you can specify the copy jobids as follows: * restore jobid=1,2,3,4,5 (where 1,2,3,4,5 are the jobids of the copy jobs) It is not the way I would expect or hope the 'copies' option would function, but at least it is "functioning as documented"™ :) Hope this helps. :) Best regards, Bill -- Bill Arlofski w...@protonmail.com ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Restoring from a copy job
Hello Josip, I think this may be a bug. I seem to recall noticing this a long time ago, and feel like I opened a Mantis about it. I was going to recommend that you upgrade from the quite old 9.x version to the 11.0.5 version currently available... But when I checked my environment, I noticed something interesting which may trigger me to open a bug report. So, I have this job called "Speedy" that gets written to removable disks, and is then copied via Bacula copy jobs to a remote Synology NFS share. I tried the following: * restore copies client=speedy-fd fileset=SpeedyFullFileSet (notice 'copies' is specified) [...snip...] To select the JobIds, you have the following choices: 1: List last 20 Jobs run 2: List Jobs where a given File is saved 3: Enter list of comma separated JobIds to select 4: Enter SQL list command 5: Select the most recent backup for a client 6: Select backup for a client before a specified time 7: Enter a list of files to restore 8: Enter a list of files to restore before a specified time 9: Find the JobIds of the most recent backup for a client 10: Find the JobIds for a backup for a client before a specified time 11: Enter a list of directories to restore for found JobIds 12: Select full restore to a specified Job date 13: Cancel Select item: (1-13): 5 <- I choose the latest backup for this client/fileset pair Then I get a list of jobids and volumes of this most recent set of backups to restore this client: ++---+--+-+-+--+ | jobid | level | jobfiles | jobbytes| starttime | volumename | ++---+--+-+-+--+ | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0030 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0036 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0040 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0021 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0034 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0032 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0035 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0028 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0038 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0017 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0043 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0031 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0039 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0019 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0025 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0027 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0020 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0024 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0023 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0016 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0037 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0041 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0011 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0042 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0015 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0022 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0029 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0033 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0026 | | 43,699 | F | 611,720 | 309,778,083,926 | 2021-11-24 23:00:01 | c0_0011_0018 | | 43,725 | I | 35,240 | 9,123,309,128 | 2021-11-25 23:00:01 | c0_0011_0014 | | 43,751 | I | 11,708 | 15,299,958,833 | 2021-11-26 23:00:01 | c0_0011_0010 | | 43,751 | I | 11,708 | 15,299,958,833 | 2021-11-26 23:00:01 | c0_0011_0014 | | 43,751 | I | 11,708 | 15,299,958,833 | 2021-11-26 23:00:01 | c0_0011_0046 | | 43,751 | I | 11,708 | 15,299,958,833 | 2021-11-26 23:00:01 | c0_0011_0045 | | 43,777 | I |4,165 | 9,470,437,163 | 2021-11-27 23:00:00 | c0_0011_0046 | | 43,803 | I |2,541 | 4,543,895,178 | 2021-11-28 23:00:00 | c0_0011_0048 | ++---+--+-+-+--+ So
[Bacula-users] Restoring from a copy job
Hello!
I am using Bacula 9.6.7 on Debian 10.x with Postgres database and
several disk/file and tape pools.
Backup is first sent to a pool containing file volumes on the disk
and after that, successful backup jobs are copied to a pool of
tapes using a Copy job.
That works as expected and I never had problems with that.
What doesn't work is the procedure for restoring from the pool of
tapes containing copies of the backup jobs.
In general, the command "restore copies client=clientname" or
"restore copies pool=poolname" should work but in my case it doesn't.
I believe that "copies" argument worked with Bacula 7.4 but cannot
confirm that any more.
I would be grateful if someone could try to restore a file from a copy
job and report the result together with the Bacula version.
In my case MediaType used for the disk pool is "disk2" and for the tape
pool it is set to "tape1".
I am using HP Ultrium LTO7 tape drive (no autochanger).
When I use "restore copies client=t-build-1-fd" command, I get the list
of both, backup jobs and copy jobs:
+-+--+---+---+
| jobid | job | copyjobid | mediatype |
+-+--+---+---+
| 129,253 | t-build-1.2021-11-29_13.57.19_09 | 129,256 | Tape1 |
+-+--+---+---+
+-+---+--+---+-+--+
| jobid | level | jobfiles | jobbytes | starttime | volumename
|
+-+---+--+---+-+--+
| 129,253 | F | 67,101 | 1,183,688,394 | 2021-11-29 13:36:29 |
diskvol-1536 |
+-+---+--+---+-+--+
You have selected the following JobId: 129253
Building directory tree for JobId(s) 129253 ...
+
61,016 files inserted into the tree.
However, when I proceed, Bacula chose to use disk2 pool containing
backup jobs instead of the tape1 pool containing copied jobs:
29-Nov 16:04 p-bkp-1-dir JobId 129801: Using Device "tape1-dev1" to read.
29-Nov 16:04 p-bkp-1-sd JobId 129801: acquire.c:115 Changing read device. Want
Media Type="File2" have="Tape1"
Tape device="tape1-dev1" (/dev/tape/by-id/scsi-3500507631216d57b-nst)
29-Nov 16:04 p-bkp-1-sd JobId 129801: Media Type change. New read File device
"disk2-dev1" (/data/disk2/volumes) chosen.
29-Nov 16:04 p-bkp-1-sd JobId 129801: Ready to read from volume "diskvol-1536"
on File device "disk2-dev1" (/data/disk2/volumes).
If I try to use restore like this: "restore copies pool=tape1
client=t-build-1-fd"
I get message such as this:
No Full backup before 2021-11-29 14:04:10 found.
If I try to use restore by setting storage like this:
"restore copies client=t-build-1-fd storage=p-bkp-1-sd-tape1"
everything looks fine at first but restore get stuck for approx.
5 minutes with the following status description:
't-build-1-restore is waiting on Storage "p-bkp-1-sd-tape1"'
Approximately 5 minutes later, restore job fails with the following
error (no other jobs are running at the moment):
29-Nov 14:14 p-bkp-1-sd JobId 129258: Fatal error: Device reservation failed
for JobId=129258:
29-Nov 14:14 p-bkp-1-dir JobId 129258: Fatal error:
Storage daemon didn't accept Device "tape1-dev1" because:
3924 Device "tape1-dev1" not in SD Device resources or no matching Media
Type or is disabled.
This is interesting because the device "tape1-dev1" is (IMHO) correctly
set in the SD configuration as well as Media Type. I checked the database
entries to be sure that pool and storage resources are correctly synced
with the database.
I don't think that I have missed something but here is the relevant
part of the SD and DIR configuration...
# Bacula SD config
Autochanger {
Name = p-bkp-1-sd-tape1
Device = tape1-dev1
Changer Command = ""
Changer Device = /dev/null
}
Device {
Name = tape1-dev1
Drive Index = 0
Device Type = Tape
Media Type = Tape1
Archive Device = /dev/tape/by-id/scsi-3500507631216d57b-nst
AutoChanger = no
LabelMedia = no
Random Access = no
AutomaticMount = yes
RemovableMedia = yes
AlwaysOpen = no
Requires Mount = no
SpoolDirectory = /var/spool/bacula/spool
Maximum Spool Size = 135G
Maximum Concurrent Jobs = 4
Control Device = /dev/tape/by-id/scsi-3500507631216d57b-nst
Alert Command = "sh -c 'smartctl -H -l error %c'"
}
# Bacula DIR config
Autochanger {
Name = p-bkp-1-sd-tape1
Address = p-bkp-1.bkp.localdomain
SDPort = 9103
Password = "strong_password"
Device = tape1-dev1
Media Type = Tape1
Autochanger = p-bkp-1-sd-tape1
Maximum Concurrent Jobs = 10
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/certs/localdomainBackupCAChain.crt
TLS Certificate =
