slm-retention.asciidoc 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119
  1. [role="xpack"]
  2. [testenv="basic"]
  3. [[slm-retention]]
  4. == Snapshot lifecycle management retention
  5. Automatic deletion of older snapshots is an optional feature of snapshot lifecycle management.
  6. Retention is run as a cluster level task that is not associated with a particular policy's schedule
  7. (though the configuration of which snapshots to keep is done on a per-policy basis). Retention
  8. configuration conists of two parts—The first a cluster-level configuration for when retention is
  9. run and for how long, the second configured on a policy for which snapshots should be eligible for
  10. retention.
  11. The cluster level settings for retention are shown below, and can be changed dynamically using the
  12. <<cluster-update-settings,cluster-update-settings>> API:
  13. |=====================================
  14. | Setting | Default value | Description
  15. | `slm.retention_schedule` | `0 30 1 * * ?` | A periodic or absolute time schedule for when
  16. retention should be run. Supports all values supported by the cron scheduler: <<schedule-cron,Cron
  17. scheduler configuration>>. Retention can also be manually run using the
  18. <<slm-api-execute-retention,Execute retention API>>. Defaults to daily at 1:30am in the master
  19. node's timezone.
  20. | `slm.retention_duration` | `"1h"` | A limit of how long SLM should spend deleting old snapshots.
  21. |=====================================
  22. Policy level configuration for retention is done inside the `retention` object when creating or
  23. updating a policy. All of the retention configurations options are optional.
  24. [source,console]
  25. --------------------------------------------------
  26. PUT /_slm/policy/daily-snapshots
  27. {
  28. "schedule": "0 30 1 * * ?",
  29. "name": "<daily-snap-{now/d}>",
  30. "repository": "my_repository",
  31. "retention": { <1>
  32. "expire_after": "30d", <2>
  33. "min_count": 5, <3>
  34. "max_count": 50 <4>
  35. }
  36. }
  37. --------------------------------------------------
  38. // TEST[setup:setup-repository]
  39. <1> Optional retention configuration
  40. <2> Keep snapshots for 30 days
  41. <3> Always keep at least 5 successful snapshots
  42. <4> Keep no more than 50 successful snapshots
  43. Supported configuration for retention from within a policy are as follows. The default value for
  44. each is unset unless specified by the user in the policy configuration.
  45. NOTE: The oldest snapshots are always deleted first, in the case of a `max_count` of 5 for a policy
  46. with 6 snapshots, the oldest snapshot will be deleted.
  47. |=====================================
  48. | Setting | Description
  49. | `expire_after` | A timevalue for how old a snapshot must be in order to be eligible for deletion.
  50. | `min_count` | A minimum number of snapshots to keep, regardless of age.
  51. | `max_count` | The maximum number of snapshots to keep, regardless of age.
  52. |=====================================
  53. As an example, the retention setting in the policy configured about would read in English as:
  54. ____
  55. Remove snapshots older than thirty days, but always keep the latest five snapshots. If there are
  56. more than fifty snapshots, remove the oldest surplus snapshots until there are no more than fifty
  57. successful snapshots.
  58. ____
  59. If multiple policies are configured to snapshot to the same repository, or manual snapshots have
  60. been taken without using the <<slm-api-execute,Execute Policy API>>, they are treated as not
  61. eligible for retention, and do not count towards any limits. This allows multiple policies to have
  62. differing retention configuration while using the same snapshot repository.
  63. Statistics for snapshot retention can be retrieved using the <<slm-get-stats,Get Snapshot Lifecycle
  64. Stats API>>:
  65. [source,console]
  66. --------------------------------------------------
  67. GET /_slm/stats
  68. --------------------------------------------------
  69. // TEST[continued]
  70. Which returns a response
  71. [source,js]
  72. --------------------------------------------------
  73. {
  74. "retention_runs": 13, <1>
  75. "retention_failed": 0, <2>
  76. "retention_timed_out": 0, <3>
  77. "retention_deletion_time": "1.4s", <4>
  78. "retention_deletion_time_millis": 1404,
  79. "policy_stats": [
  80. {
  81. "policy": "daily-snapshots",
  82. "snapshots_taken": 1,
  83. "snapshots_failed": 1,
  84. "snapshots_deleted": 0, <5>
  85. "snapshot_deletion_failures": 0 <6>
  86. }
  87. ],
  88. "total_snapshots_taken": 1,
  89. "total_snapshots_failed": 1,
  90. "total_snapshots_deleted": 0, <7>
  91. "total_snapshot_deletion_failures": 0 <8>
  92. }
  93. --------------------------------------------------
  94. // TESTRESPONSE[skip:this is not actually running retention]
  95. <1> Number of times retention has been run
  96. <2> Number of times retention failed while running
  97. <3> Number of times retention hit the `slm.retention_duration` time limit and had to stop before deleting all eligible snapshots
  98. <4> Total time spent deleting snapshots by the retention process
  99. <5> Number of snapshots created by the "daily-snapshots" policy that have been deleted
  100. <6> Number of snapshots that failed to be deleted
  101. <7> Total number of snapshots deleted across all policies
  102. <8> Total number of snapshot deletion failures across all policies