Hi, Correct. Using "location=backupfolder" didn't work for me.
The only way I made it work is with location=s3:/ Below my sample url which works well. http://servername:8983/solr/admin/collections?action=BACKUP&name=personbackup&collection=person&repository=s3&location=s3:/ On Tue, 25 Jan 2022 at 17:23, Houston Putman <[email protected]> wrote: > Thanks for all of the information everybody. I want to determine if this is > actually a bug before we release 9.0 > > First, I want to clear up the usage of the "location" parameter: > > - It is required, but you can provide "/" as an "empty" directory, much > like "s3:/". > - You don't have to include "s3:/" or "s3://". You can you "/dir", > "dir", "s3:/dir" or "s3://dir". All of these options will eventually be > converted to the "dir/" directory in your bucket. > - The s3 repository does not allow for directory names starting with > "/". In general this is to allow all of the above ^ examples to compute > to > the same thing without users being confused how many '/'s they need > after > "s3:". Now I see that this may have contributed to the confusion, but we > can always improve the documentation in the ref-guide. > > Now with these points cleared up, you said that you were unable to use the > collections API calls with "location=backupfolder" did not work, even > though you had a directory in your bucket named "backupfolder". Just to be > clear, in S3 the folder did not have a "/" prefix correct? If so, this is > indeed a bug and something that we should fix. I'll do more thorough > testing once you confirm that the directory is following the expectation. > > - Houston > > On Sat, Jan 22, 2022 at 3:32 AM Shawn Heisey <[email protected]> wrote: > > > On 1/22/2022 12:38 AM, Sergio García Maroto wrote: > > > The only difference I can see i am using collection API trying to > backup > > > solr cloud collection. > > > > That could do it. I have done very little with SolrCloud beyond > > occasionally firing up the cloud example. > > > > The Collections API backup is most likely a different code path than the > > replication handler backup. I wonder if the behavior you're seeing > > would be considered a bug. > > > > Thanks, > > Shawn > > >
