@@ -51,7 +51,7 @@ snapshot. When a snapshot is restored to the Catalog, the Compactor
51
51
- [ Resources] ( #resources )
52
52
- [ prep_pg_dump.awk] ( #preppgdumpawk )
53
53
54
- ### Soft delete
54
+ ## Soft delete
55
55
56
56
A _ soft delete_ refers to when, on compaction, the Compactor sets a ` deleted_at `
57
57
timestamp on the Parquet file entry in the Catalog.
@@ -63,23 +63,22 @@ longer queryable, but remains intact in the object store.
63
63
A _ hard delete_ refers to when a Parquet file is actually deleted from object
64
64
storage and no longer exists.
65
65
66
-
67
66
## Recovery Point Objective (RPO)
68
67
69
68
RPO is the maximum amount of data loss (based on time) allowed after a disruptive event.
70
69
It indicates how much time can pass between data snapshots before data is considered lost if a disaster occurs.
71
70
72
71
The InfluxDB Clustered snapshot strategy RPO allows for the following maximum data loss:
73
72
74
- - 1 hour for hourly snapshots _ (up to the configured hourly snapshot expiration)_
75
- - 1 day for daily snapshots _ (up to the configured daily snapshot expiration)_
73
+ - 1 hour for hourly snapshots _ (up to the configured hourly snapshot expiration)_
74
+ - 1 day for daily snapshots _ (up to the configured daily snapshot expiration)_
76
75
77
76
## Recovery Time Objective (RTO)
78
77
79
78
RTO is the maximum amount of downtime allowed for an InfluxDB cluster after a failure.
80
79
RTO varies depending on the size of your Catalog database, network speeds
81
- between the client machine and the Catalog database, cluster load, the status
82
- of your underlying hosting provider, and other factors.
80
+ between the client machine and the Catalog database, cluster load, the status
81
+ of your underlying hosting provider, and other factors.
83
82
84
83
## Data written just before a snapshot may not be present after restoring
85
84
0 commit comments