It'd work fine, I played around with this a bit once upon a time.
The trick is that you need to either:
1. Make sure all shards for the index are synchronized onto every node for the
duration of the restore (as you mention)
2. Know exactly which nodes will ask to restore which shards for the duration
of the restore
But the former isn't tenable if you're sharding due to space constraints, and
the latter can't be easily predicted.
On 3/28/18, 11:30 AM, "Shawn Heisey" <apa...@elyograg.org> wrote:
On 3/28/2018 10:34 AM, Jeff Wartes wrote:
> The backup/restore still requires setting up a shared filesystem on all
your nodes though right?
Technically speaking, I don't think a shared filesystem is actually
REQUIRED to make a backup.
But in order to do a restore, all machines involved with the restore
must have access to all of the data written by all of the machines that
made the backup.
The easiest way to accommodate the restore requirements is to have all
the servers use the same network-mounted filesystem, mounted in the same
location.
One thing that I think you COULD do is have each server make its backup
into a local filesystem, and then use some kind of synchronization tool
(rsync, robocopy, and others) to ensure that every system has an
identical copy of ALL the data, and allow that synchronization to finish
before attempting a restore. It could be challenging to do the
synchronization successfully without accidentally deleting part of the
data. The shared filesystem is likely to be easier.
Someone who's more familiar with the feature should comment on whether
that synchronization idea will actually work. If the backup/restore
functionality is written the way I would *expect* it to be written, it
should work.
Thanks,
Shawn
