I guess you could do a version-independent backup with /export handler and store docs in XML or JSON format. Or you could use streaming and store the entire index as JSON tuples, which could then be ingested into another version.
But it is correct that the backup/restore feature of Solr is not primarily intended for archival or moving a collection to a completely different version. It is primarily intended as a much faster disaster recovery method than reindex from slow sources. But you COULD also use it to quickly migrate from an old cluster to the next major version. It would be cool to investigate an alternate backup command, which instructs each shard leader to stream all documents to JSON inside the backup folder, in parallell. But you may still get issues with the Zookeeper part if restoring to a very different version. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 18. sep. 2018 kl. 17:24 skrev Walter Underwood <wun...@wunderwood.org>: > > It isn’t very clear from that page, but the two backup methods make a copy > of the indexes in a commit-aware way. That is all. One method copies them > to a new server, the other to files in the data directory. > > Database backups generally have a separate backup format which is > independent of the database version. For example, mysqldump generates > a backup as SQL statements. > > The Solr backup is version-locked, because it is just a copy of the index > files. > People who are used to database backups might be very surprised when they > could not load a Solr backup into a server with a different version or on a > different architecture. > > The only version-independent restore in Solr is to reload the data from the > source repository. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > >> On Sep 18, 2018, at 8:15 AM, Christopher Schultz >> <ch...@christopherschultz.net> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Walter, >> >> On 9/17/18 11:39, Walter Underwood wrote: >>> Do not use Solr as a database. It was never designed to be a >>> database. It is missing a lot of features that are normal in >>> databases. >>> >>> [...] * no real backups (Solr backup is a cold server, not a >>> dump/load) >> >> I'm just curious... if Solr has "no real backups", why is there a >> complete client API for performing backups and restores? >> >> https://lucene.apache.org/solr/guide/7_4/making-and-restoring-backups.ht >> ml >> >> Thanks, >> - -chris >> -----BEGIN PGP SIGNATURE----- >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluhFp8ACgkQHPApP6U8 >> pFgnhBAAre3Zb2mu++WVmY6rZlcc3uoRkDRva6iR602wA/w/EUabCmHEkO9maYEm >> NoUREgBH9NtFPvYnjkEEL7/P/2hUErvRw0RfwsAo89ClYjjyMEH25+p5SNmudUmK >> fKRSLRUyCbpE8ahKTPG44gRlki03uJJ2GA0r3vbTLvdqm1p5KO6sE4k/r3IYJ0QI >> qZfUY4Un+LQ5vGMQ7qeGRcFhaAXVOaJmnLCRqGTS2hMTM1uM01TCblhOaeX5XHYD >> Yra4m15Sr1H8p3S0CFsP8oqvDND0jEC4MxM9mQvHOvq9IwMreTSwACga35Wm6ItD >> h1/Td9H/Puo8o9vQMaVfNcFD4TAqt+FkIHzQEb+FkQAMfbC9ZHsmBgvl8EUtPBq1 >> h2ODETEcD5SsmdfrP5OWUz+0OBhH7/HEgWRjHW9nSMzhPn4kYgpF/7VuFL8iy3re >> /8TviTf446I859QNragWXACdARhCzMo8AoXIs/dC70CGDvxuKmEcI6tad9Zsxcf2 >> +yaFa3Fzddulaeao4juZVbRVJ9eewFOSawMXDc14TeL6t13CxzxFasHiYu0C5euV >> XhKSWEHYj58ijS/KU4FMDCEWZhr1KWEKwfVp7hZ2CZZNW5kNPbv97otKvxB0cKyS >> LTK6PtZoZbTWXFa8rT3yq28/x6gMULQeo0ZBZLTXEJKpfAT2vAU= >> =Fh1S >> -----END PGP SIGNATURE----- >
