{"_id":"5ae396d6ad609b000336c845","project":"5633ebff7e9e880d00af1a53","version":{"_id":"5a8fae0268264c001f20cc00","project":"5633ebff7e9e880d00af1a53","__v":2,"createdAt":"2018-02-23T06:00:34.961Z","releaseDate":"2018-02-23T06:00:34.961Z","categories":["5a8fae0268264c001f20cc01","5a8fae0268264c001f20cc02","5a8fae0368264c001f20cc03","5a8fae0368264c001f20cc04","5a8fae0368264c001f20cc05","5a8fae0368264c001f20cc06","5a8fae0368264c001f20cc07","5a8fae0368264c001f20cc08","5a8fae0368264c001f20cc09","5abaa7eb72d6dc0028a07bf3"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"2.0.0","version":"2.0"},"category":{"_id":"5a8fae0368264c001f20cc04","version":"5a8fae0268264c001f20cc00","project":"5633ebff7e9e880d00af1a53","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-05-31T04:26:39.925Z","from_sync":false,"order":4,"slug":"versions","title":"Bonsai.io Platform"},"user":"5637d336aa96490d00a64f81","githubsync":"","__v":0,"parentDoc":null,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2018-04-27T21:32:06.424Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":7,"body":"The [Snapshot and Restore](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html) feature is a really nice set of tools for backing up and restoring your data. Because Bonsai is a managed service that offers a [multitenant architecture](doc:architecture-classes#multi-tenant-class), there are some limits on how it can be used.\n[block:api-header]\n{\n  \"title\": \"How Does Bonsai Manage Snapshots?\"\n}\n[/block]\nBonsai takes regular, automatic backups of all paid clusters, and stores them in an encrypted S3 bucket in the same region as the cluster. These snapshots are taken at the start of every hour and are retained for two weeks.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"In some rare cases, you may see an error like this when attempting to alter an index:\\n\\n```\\nCannot delete indices that are being snapshotted: [[my_index/dPzLciT9RlmS8OtGGm61IQ]]. Try again after snapshot finishes or cancel the currently running snapshot.\\n```\\n\\nThis is happening because the action is taking place during the regular snapshot. Snapshots happen at the start of every hour (00:00, 01:00, 02:00, etc), and can take anywhere from a few seconds to a few minutes. If you attempt to delete your index during this time, the action will be blocked.\\n\\nThe solution is to wait a minute or two and try again.\",\n  \"title\": \"HTTP 400: Cannot delete indices that are being snapshotted\"\n}\n[/block]\nIn the unlikely event that your cluster suffers unrecoverable data loss (for example: a node hosting primary data is lost, and there's no replica), then we will use the most recent successful snapshot to restore the data. Any data updates from the time of the snapshot to the time of its restoration will need to be reindexed.\n[block:api-header]\n{\n  \"title\": \"Can I Take My Own Snapshots?\"\n}\n[/block]\nNot at this time. The technical explanation is that snapshot and restore operations can be extremely demanding on IO, and Elasticsearch will only allow one snapshot/restore operation to occur at a time, with subsequent calls sitting in a queue. \n[block:callout]\n{\n  \"type\": \"success\",\n  \"title\": \"We're Always Improving\",\n  \"body\": \"We're working on ways of making snapshot and restore features safer and easier to use on the Bonsai platform. If you have an idea or use case you'd like to see supported, [shoot us an email](mailto:support:::at:::bonsai.io) and we'll evaluate adding it to our development pipeline.\"\n}\n[/block]\nIf you've read the article on [Architecture Classes](doc:architecture-classes), specifically the section on Multi Tenant Class clusters, you'll understand why this is problematic. Users with unrestrained access to that API could inadvertently take down a group of nodes with some ill-timed calls. Or, an impatient user wondering why his/her snapshot isn't processing right away may repeat the call multiple times, populating the queue. It's also plausible that a less experienced user may attempt taking a snapshot a minute.\n\nSomething to consider is the purpose of the snapshot. If your desire is simply to have an up to date backup, then Bonsai is already handling that with hourly snapshots. If the desire is to restore the snapshot locally, or to another cluster for testing/dev purposes, we may be able to accommodate through our [support channels](mailto:support@bonsai.io).\n[block:api-header]\n{\n  \"title\": \"I Need More Frequent Snapshots / Longer Retention!\"\n}\n[/block]\nWe can provide custom SLA's -- including more frequent snapshots and longer retention times for users on Enterprise plans. Send an email to [support](mailto:support@bonsai.io) with your requirements and we'll put together a quote.\n[block:api-header]\n{\n  \"title\": \"I Have My Own S3 Bucket -- Can You Just Use That?\"\n}\n[/block]\nThe encrypted buckets we use are set up and managed automatically. It's possible to have snapshots added to a different bucket, but only for [single tenant configurations](doc:architecture-classes#single-tenant-class). If you're on a Dedicated, Business or Enterprise tier cluster, please [send us a note](mailto:support@bonsai.io) and we'll see what we can do.","excerpt":"","slug":"how-bonsai-manages-snapshots","type":"basic","title":"Snapshots on Bonsai"}

Snapshots on Bonsai


The [Snapshot and Restore](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html) feature is a really nice set of tools for backing up and restoring your data. Because Bonsai is a managed service that offers a [multitenant architecture](doc:architecture-classes#multi-tenant-class), there are some limits on how it can be used. [block:api-header] { "title": "How Does Bonsai Manage Snapshots?" } [/block] Bonsai takes regular, automatic backups of all paid clusters, and stores them in an encrypted S3 bucket in the same region as the cluster. These snapshots are taken at the start of every hour and are retained for two weeks. [block:callout] { "type": "info", "body": "In some rare cases, you may see an error like this when attempting to alter an index:\n\n```\nCannot delete indices that are being snapshotted: [[my_index/dPzLciT9RlmS8OtGGm61IQ]]. Try again after snapshot finishes or cancel the currently running snapshot.\n```\n\nThis is happening because the action is taking place during the regular snapshot. Snapshots happen at the start of every hour (00:00, 01:00, 02:00, etc), and can take anywhere from a few seconds to a few minutes. If you attempt to delete your index during this time, the action will be blocked.\n\nThe solution is to wait a minute or two and try again.", "title": "HTTP 400: Cannot delete indices that are being snapshotted" } [/block] In the unlikely event that your cluster suffers unrecoverable data loss (for example: a node hosting primary data is lost, and there's no replica), then we will use the most recent successful snapshot to restore the data. Any data updates from the time of the snapshot to the time of its restoration will need to be reindexed. [block:api-header] { "title": "Can I Take My Own Snapshots?" } [/block] Not at this time. The technical explanation is that snapshot and restore operations can be extremely demanding on IO, and Elasticsearch will only allow one snapshot/restore operation to occur at a time, with subsequent calls sitting in a queue. [block:callout] { "type": "success", "title": "We're Always Improving", "body": "We're working on ways of making snapshot and restore features safer and easier to use on the Bonsai platform. If you have an idea or use case you'd like to see supported, [shoot us an email](mailto:support@bonsai.io) and we'll evaluate adding it to our development pipeline." } [/block] If you've read the article on [Architecture Classes](doc:architecture-classes), specifically the section on Multi Tenant Class clusters, you'll understand why this is problematic. Users with unrestrained access to that API could inadvertently take down a group of nodes with some ill-timed calls. Or, an impatient user wondering why his/her snapshot isn't processing right away may repeat the call multiple times, populating the queue. It's also plausible that a less experienced user may attempt taking a snapshot a minute. Something to consider is the purpose of the snapshot. If your desire is simply to have an up to date backup, then Bonsai is already handling that with hourly snapshots. If the desire is to restore the snapshot locally, or to another cluster for testing/dev purposes, we may be able to accommodate through our [support channels](mailto:support@bonsai.io). [block:api-header] { "title": "I Need More Frequent Snapshots / Longer Retention!" } [/block] We can provide custom SLA's -- including more frequent snapshots and longer retention times for users on Enterprise plans. Send an email to [support](mailto:support@bonsai.io) with your requirements and we'll put together a quote. [block:api-header] { "title": "I Have My Own S3 Bucket -- Can You Just Use That?" } [/block] The encrypted buckets we use are set up and managed automatically. It's possible to have snapshots added to a different bucket, but only for [single tenant configurations](doc:architecture-classes#single-tenant-class). If you're on a Dedicated, Business or Enterprise tier cluster, please [send us a note](mailto:support@bonsai.io) and we'll see what we can do.