esxi nvram esxi nvram要备份吗

转载

mob64ca141834d3 2024-04-23 18:08:38

文章标签 esxi nvram elasticsearch 数据 sed API 文章分类 架构后端开发

备份集群
随着存储数据软件的发展，常规性的备份数据越来越重要。Elasticsearch的replicas提供了运行时的高可用性；在服务不中断的情况下，允许不定时的节点宕机。
然而，Repalicas并不提供针对灾难性失败的保护。因此，你需要实时的备份你的集群–一份完整的拷贝，以备不时之需。
备份集群，你需要用到snapshot API.它会将集群当前的状态和数据保存到共享库中。这种备份的过程是“smart”。你的第一个快照将是完整的数据副本，后续的快照将保存现有的快照和新数据之间的增量。随着时间的推移，数据将逐步添加和删除，这意味着后续备份将大大加快，因为它们传输的数据少的多。
要想使用该功能，你首先需要创建一个仓库来保存数据，有以下几种可选择的仓库类型。

 Shared filesystem, such as a NAS 
  Amazon S3 
  HDFS (Hadoop Distributed File System) 
  Azure Cloud创建仓库 
 让我们创建一个共享文件系统仓库： 
 PUT _snapshot/my_backup 
 { 
 “type”: “fs”, 
 “settings”: { 
 “location”: “/mount/backups/my_backup” 
 } 
 }提供仓库名，在这里我们叫做my_backup
具体挂载一种共享文件系统的数据仓库类型
最后，我们提供一个目标路径地址

注意：共享文件系统路径必须能够被集群中的所有节点访问。这将会在挂载点中创建仓库和所需元数据。你还可以设置其他选项，取决于节点、网络和仓库位置的性能配置文件。 
 max_snapshot_bytes_per_sec 
 该项用于设置快照数据进入仓库的流速，默认是20M每秒。 
 max_restore_bytes_per_sec 
 当从仓库恢复数据的时候，该项用于控制恢复的数据流速，为的是让网络不饱和。默认是20M每秒。假设我们有快速的网络，可以处理额外的流量，我们可以增加一下默认值。
POST _snapshot/my_backup/ 
 { 
 “type”: “fs”, 
 “settings”: { 
 “location”: “/mount/backups/my_backup”, 
 “max_snapshot_bytes_per_sec” : “50mb”, 
 “max_restore_bytes_per_sec” : “50mb” 
 } 
 } 
 注意：我们使用POST代替PUT,将会更新存在的设置。 
 然后增加我们的settings。快照所有的索引
仓库可能包含多个快照。每个快照可能包含特定数量索引（例如，所有的，几个，或者一个）。当创建仓库时，需要指定快照哪些索引，并给快照一个名称。
最基本的快照命令： 
 PUT _snapshot/my_backup/snapshot_1这将会备份所有的索引到my_backup库中，名称叫snapshot_1的快照中。这次请求会很快返回，快照进程会在后台执行。
建议：通常你会想让你的快照进程作为后台进程，但是偶尔你也想在你的脚本中等待完成，你可以增加wait_for_completion 标志。 
 PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true 
 这次请求将会阻塞，直到快照完成，因此大数据量的快照可能会等很长时间。快照特定索引
默认行为是快照着所有开放的索引。但是你可能使用了Marvel，不想快照以.marvel结尾的索引，又或者说你没有足够的空间来备份所有的索引。
这种情况下，当快照你的集群的时候，你可以指定特定的索引名称。 
 PUT _snapshot/my_backup/snapshot_2 
 { 
 “indices”: “index_1,index_2” 
 } 
 这次快照将只会快照index_1,index_2两个索引。查看快照相关的信息 
 一旦你逐渐积累仓库中的快照，或许你会忘记特定快照的相关信息，尤其是当快照名称命名是基于时间界限的（例如，backup_2014_10_28）。为了获取单个快照的信息，仅仅通过GET请求并带上具体的仓库名称和快照名称即可。 
 GET _snapshot/my_backup/snapshot_2 
 它将会返回与该快照相关的简要信息。 
 { 
 “snapshots”: [ 
 { 
 “snapshot”: “snapshot_1”, 
 “indices”: [ 
 “.marvel_2014_28_10”, 
 “index1”, 
 “index2” 
 ], 
 “state”: “SUCCESS”, 
 “start_time”: “2014-09-02T13:01:43.115Z”, 
 “start_time_in_millis”: 1409662903115, 
 “end_time”: “2014-09-02T13:01:43.439Z”, 
 “end_time_in_millis”: 1409662903439, 
 “duration_in_millis”: 324, 
 “failures”: [], 
 “shards”: { 
 “total”: 10, 
 “failed”: 0, 
 “successful”: 10 
 } 
 } 
 ] 
 } 
 如果你想获取仓库中所有的快照，使用_all来代替快照名称。 
 GET _snapshot/my_backup/_all删除快照 
 最后，我们需要通过命令来删除已经不再使用得旧的快照。通过DELETE 的HTTP请求，来调用对应的仓库/快照名称。 
 DELETE _snapshot/my_backup/snapshot_2 
 使用API来删除快照是极其重要的，因为没有其它机制。快照是增量的，可能很多的快照依赖于旧的部分。Delete API能够理解那些数据在最近的快照中使用，并且删除旧的部分。 
 然而，如果你手动删除文件，会存在中断备份的风险，因为你删除了正在使用的数据。监控快照过程 
 Wait_for_completion标志提供了基本的监控信息，但是对于快照或者恢复集群，显然是不够的。另外两个API将会给出更多的关于快照状态的信息。首先你应当通过GET请求获取快照ID，正如我们之前获取信息所做的一样。 
 GET _snapshot/my_backup/snapshot_3 
 如果当你请求的时候，快照进程正在运行，你将会看到快照什么时候开始的、已经运行了多久等信息。注意，这个API和快照使用的是同一个线程池。如果快照大的分片时，更新的时间可能会很长，因为二者会竞争线程池的资源。一个更好的API选择： 
 GET _snapshot/my_backup/snapshot_3/_status 
 _status能够立即返回并给出更多的统计信息：{ 
 “snapshots”: [ 
 { 
 “snapshot”: “snapshot_3”, 
 “repository”: “my_backup”, 
 “state”: “IN_PROGRESS”, 
 “shards_stats”: { 
 “initializing”: 0, 
 “started”: 1, 
 “finalizing”: 0, 
 “done”: 4, 
 “failed”: 0, 
 “total”: 5 
 }, 
 “stats”: { 
 “number_of_files”: 5, 
 “processed_files”: 5, 
 “total_size_in_bytes”: 1792, 
 “processed_size_in_bytes”: 1792, 
 “start_time_in_millis”: 1409663054859, 
 “time_in_millis”: 64 
 }, 
 “indices”: { 
 “index_3”: { 
 “shards_stats”: { 
 “initializing”: 0, 
 “started”: 0, 
 “finalizing”: 0, 
 “done”: 5, 
 “failed”: 0, 
 “total”: 5 
 }, 
 “stats”: { 
 “number_of_files”: 5, 
 “processed_files”: 5, 
 “total_size_in_bytes”: 1792, 
 “processed_size_in_bytes”: 1792, 
 “start_time_in_millis”: 1409663054859, 
 “time_in_millis”: 64 
 }, 
 “shards”: { 
 “0”: { 
 “stage”: “DONE”, 
 “stats”: { 
 “number_of_files”: 1, 
 “processed_files”: 1, 
 “total_size_in_bytes”: 514, 
 “processed_size_in_bytes”: 514, 
 “start_time_in_millis”: 1409663054862, 
 “time_in_millis”: 22 
 } 
 }, 
 …

一个快照正在缓慢运行，正如它的状态显示的那样：IN_PROGRESS
这个快照仍有一个分片在传输数据(其它四个已经完成)。

响应包括快照的整体状态，同时还可以下钻为每个索引和每个分片的统计信息。这给你一个令人难以置信的详细视图，快照进展如何。每个分片可以处于不同的完成状态。
INITIALIZING
分片正在检查集群状态看是否可以快照，这通常会很快
STARTED
数据正在传输数据到存储库中
FINALIZING
数据传输已完成，分片正在发送快照元数据
DONE
快照完成
FAILED
快照过程中遇到错误，这个分片/索引/快照没能完成，可以通过检查日志获取更多信息。

取消快照
最后，您可能需要取消快照或还原。因为这是一个长期运行的过程，在执行的过程中，你可能会出现错误，因此可能需要很长的时间来解决问题，而又不想让其占用宝贵的资源。

取消快照，当其执行的过程中，删除快照即可。
DELETE _snapshot/my_backup/snapshot_3
这将会暂停快照的过程，然后从仓库中删除未完成的快照。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。