Hey Artem,

Incremental backups were written primarily with SolrCloud in mind.
Many of the APIs (backup listing, backup deletion, etc.) work only in
SolrCloud, and most of our automated tests around backups focus on
SolrCloud setups.

That said, incremental backup in SolrCloud relies on doing incremental
backup at the core-level, and there are internal APIs that expose this
that you can hit in standalone mode if you'd really like to.  These
APIs are considered "internal", so they're subject to change and
intended for Solr's own use under the hood and they're a bit ugly.
But it is possible to use them in standalone mode for doing
backup/restore.

In general the backupcore API call looks like:

/solr/admin/cores?
    action=BACKUPCORE&
    core=coreName&
    shardBackupId=md_coreName_1&
    prevShardBackupId=md_coreName_0&
    repository=someBackupRepoName&
    location=/some/location

'action' and 'core' should be pretty self-explanatory.

The 'repository' and 'location' parameters are explained in the
collection-level docs here:
https://solr.apache.org/guide/8_10/collection-management.html#backup-parameters.
There's also more info here on 'repository' in particular:
https://solr.apache.org/guide/8_10/making-and-restoring-backups.html#backuprestore-storage-repositories

(Note that the 'location' should already exist, and should contain two
subdirectories: 'index', and 'shard_backup_metadata'.  These are
details that are handled for users in SolrCloud, but that need to be
handled manually when using the core-level APIs in standalone mode.)

The least intuitive parameters are 'shardBackupId' and
'prevShardBackupId'.  In a standalone/core-level frame of reference,
these effectively name the current backup ('shardBackupId') and
provide a pointer to the previous incremental backup for the core
('prevShardBackupId') if there is one.  The values for these params
are pretty inflexible: I'd advocate always using 'md_coreName_0',
'md_coreName_1', 'md_coreName_2', etc.

So on successive backups of the same core, you might use params like:
- 
"action=BACKUPCORE&core=coreName&shardBackupId=md_coreName_0&repository=someRepo&location=/some/location"
- 
"action=BACKUPCORE&core=coreName&shardBackupId=md_coreName_1&prevShardBackupId=md_coreName_0&repository=someRepo&location=/some/location"
- and so on.

TL;DR - there are "internal" APIs for incremental backups in
standalone mode, but (at this point) they're an implementation detail
of the SolrCloud support that's subject to change. Standalone users
should exercise their best judgement in deciding whether to use these,
or some of the other standalone backup options
(/replication?command=backup, /solr/admin/cores?action=CREATESNAPSHOT,
etc.)

Best,

Jason

On Sun, Nov 14, 2021 at 9:53 PM Abeleshev Artyom <abeles...@gmail.com> wrote:
>
> On the previous version of Solr (started from 8.9) a new incremental backup
> support has been added. It was based on the following proposal
> https://cwiki.apache.org/confluence/display/SOLR/SIP-12%3A+Incremental+Backup+and+Restore.
> JIRA issue https://issues.apache.org/jira/browse/SOLR-15086 for the SIP
> that was used for managing subtasks is closed with the comment that all the
> included proposals are being implemented. I see some updates on
> documentation for using incremental backup for SolrCloud, but what about
> Standalone Solr? Is there a reason why it is not announced that incremental
> support is also added for Standalone Solr? I don't see any mentions about
> incremental backup on Standalone Solr documentation. I've checked the
> sources and it seems that everything is in place and support is included
> (subissue https://issues.apache.org/jira/browse/SOLR-13608 was closed at
> version 8.9). Is it still not reliable and incremental backups have some
> issues? Or maybe just forgot to update documentation files?
>
> Best regards,
> Artem Abeleshev

Reply via email to