Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOC-2342 Refine point-in-time-restore description (4.1) #517

Open
wants to merge 2 commits into
base: 4.1
Choose a base branch
from
Open

DOC-2342 Refine point-in-time-restore description (4.1) #517

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4da2d25
Update point-in-time-restore.adoc
arun-TG-PM Sep 3, 2024
005a2d9
Merge branch '4.1' into arun-TG-PM-patch-1
victorleeTG Nov 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions modules/backup-and-restore/pages/point-in-time-restore.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,9 +62,9 @@ The primary advantage of Point-in-Time Restore is the flexibility it offers, all
. The changes made between Tuesday 10pm and Wednesday 1:55pm are saved this way.
====

Summery of key benefits:
Summary of key benefits:

* Precise recover time point to save a much as possible correct work made to database.
* Precise recover time point to save as much as possible correct work made to database.


== Limitations and Considerations
Expand All @@ -77,6 +77,6 @@ image::PIT_restore.png[]
* GSQL Content: The GSQL content, such as schemas and RBAC settings, cannot be restored to the exact version at the provided time point. After a Point-in-Time Restore, these elements will reflect the version of the nearest differential backup used.
* Precision Window: Point-in-Time Restore operates with a precision window of a few minutes. To ensure optimal data consistency, it is recommended to restore to a time point at least 2-3 minutes before the timestamp of any unwanted changes.
* Coverage: Point-in-Time Restore cannot be performed for timestamps not covered by an existing differential backup. If the desired time point is not covered, a new differential backup must be created before performing the restore.
** To maximize the potential of Point-in-Time Restore, users are expected to do backups regulary. A good example can be doing weekly full backup and daily differential backup in days between two full backups.
** To maximize the effectiveness of Point-in-Time Restore, it’s recommended to perform weekly full backups and daily differential backups. This routine helps ensure that any desired restore point is covered and available when needed.