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 pr
The only hard-and-fast rule is that you must re-index from source when
you upgrade to Solr X+2. Solr (well, Lucene) tries very hard to
maintain one-major-version back-compatibility, so Solr 8 will function
with Solr 7 indexes but _not_ any index _ever touched_ by 6x.
That said, it's usually a good
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Walter,
On 9/18/18 11:24, Walter Underwood wrote:
> 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 d
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 data
-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,
