Le mardi 14 juin 2016 16:57:29 UTC+2, marco.van.wieringen a écrit : > On 06/13/16 10:37 PM, Douglas K. Rand wrote: > > On 06/13/16 14:00, Franck Ratier wrote: > >> On Monday, 13 June 2016 10:10:24 UTC+1, [email protected] wrote: > >>> I configured copies and it work fine. > >>> > >>> Now, I want perform some restorations tests but I have an issue : I > >>> run "restore client=<client_name> copies". > >>> > >>> I show correctly jobID and copyjobId but it automatically select > >>> jobId instead of copyjobId. If I continue (mark some files to > >>> restore), it restore from original storage instead of storage of > >>> copies. > Looking at the implementation it only lists the copies indeed so it > seems to be what the original design was when that was added. It does > not update the list of JobIds its uses for restore. So I guess you just > run into the fact that the design does not allow you to restore from > copies. > > >>> > >>> But if I run restore with "restore client=<client_name> copies > >>> jobid=<copyjobId>", it will restore from the storage of copies. > >>> > >>> If I specify "copies" in the first case, should it not use copy > >>> storage directly ? > That might be what you expect but that is not what the person who > implemented it thought it should do or it was never finished. > > > > >> I think that until the original job has not expired (i.e. retention > >> time not expired), the copy "is just a copy". Once the original job > >> expires the copy will be promoted and will be used for any restore > >> you'd have to do. It's well explained in the docs, Chapter 22 - > >> Migration and Copy. > Correct normally you have the original Job on fast storage lets say > disk and you copy to tape. So then you want to restore from disk and > when things expire on disk the copy on take gets "promoted" to a normal > Job and as such is available for restore. > > > > > I find myself in exactly the same spot as Sylvain does: Testing that I > > can restore from the tape based copies I made of my on-disk backups. > > > > I've tried several purge commands to try to remove the records of the > > original backup from the catalog, but I still cannot restore from the > > copy jobs. > > > > Any suggestions on how to go about this testing? > Currently you probably need to migrate as then the original job gets removed. > > I might have a stab to see if a simple extra SQL query to retrieve the copies > can be run when you say you explicitly want to use copies to restore. I could > imagine that it makes sense when you loose a site and have sd-sd replication > to an other datacenter. Problem is however that you can then only have one > copy as otherwise it gets kind of difficult to select what copies to use. > > -- > Marco van Wieringen [email protected] > Bareos GmbH & Co. KG Phone: +49-221-63069389 > http://www.bareos.com > > Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 > Komplementär: Bareos Verwaltungs-GmbH > Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens, > P. Storz, M. v. Wieringen
Thanks for all these informations. After some tests, I will adapt to this operation. If I manually purge volumes, bconsole uses directly copies jobs whithout intervention. Sylvain -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
