Thanks, Jason, for the detailed answer. Now I got the point and It makes sense.
Best regards, Artem Abeleshev On Mon, Nov 15, 2021 at 10:05 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > 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 >
