Docs: RestoreFromBackup --restore_to_timestamp

content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/overview.md

@@ -37,7 +37,7 @@ Generally speaking and on most workloads, the cost of a full backup is higher, a
 
 Full and incremental backups are expected to be interleaved. For example: one would create a full backup once per day, and incremental backups once per hour.
 
-Full backups are simply states of the database. Incremental backups, however, need to start with some point and end with some point. The common practice is for an incremental backup to continue from the point of the last good backup, which can be a full or incremental backup. An inremental backup in Vitess end at the point in time of execution.
+Full backups are simply states of the database. Incremental backups, however, need to start with some point and end with some point. The common practice is for an incremental backup to continue from the point of the last good backup, which can be a full or incremental backup. An inremental backup in Vitess ends at the point in time of execution.
 
 The identity of the tablet on which a full backup or an incremental backup is taken is immaterial. It is possible to take a full backup on one tablet and incremental backups on another. It is possible to take full backups on two different tablets. It is also possible to take incremental backups, independently, on two different tablets, even though the contents of those incremental backups overlaps. Vitess uses MySQL GTID sets to determine positioning and prune duplicates.
 

content/en/docs/18.0/user-guides/operating-vitess/backup-and-restore/bootstrap-and-restore.md

@@ -56,7 +56,21 @@ If successful, the tablet's MySQL server rejoins the shard's replication stream,
 
 ### Restore to a point-in-time
 
-`v17` supports incremental restore, or restoring to a specific _position_:
+Vitess supports restoring to a _timestamp_ or to a specific _position_. Either way, this restore method assumes backups have been taken that cover the specified position. The restore process will first determine a restore path: a sequence of backups, starting with a full backup followed by zero or more incremental backups, that when combined, include the specified timestamp or position. See more on [Restore Types](../overview/#restore-types) and on [Taking Incremental Backup](../creating-a-backup/#create-an-incremental-backup-with-vtctl).
+
+#### Restore to timestamp
+
+Starting with `v18`, it is possible to restore to a given timestamp. The restore process will apply all events up to, and excluding, the given timestamp, at 1 second granularity. That is, the restore will bring the database to a point in time which is _about_ 1 second before the specified timestamp. Example:
+
+```shell
+$ vtctlclient -- RestoreFromBackup --restore_to_timestamp "2023-06-15T09:49:50Z" zone1-0000000100
+```
+
+The timestamp must be in `RFC3339` format.
+
+#### Restore to a position
+
+It is possible to restore onto a precise GTID position. Vitess will restore up to, and including, the exact requested position. This gives you the utmost granularity into the state of the restored database.
 
 ```shell
 vtctlclient -- RestoreFromBackup --restore_to_pos <position> <tablet-alias>
@@ -68,6 +82,4 @@ Example:
 vtctlclient -- RestoreFromBackup --restore_to_pos "MySQL56/0d7aaca6-1666-11ee-aeaf-0a43f95f28a3:1-60" zone1-0000000102
 ```
 
-This restore method assumes backups have been taken that cover the specified position. The restore process will first determine a restore path: a sequence of backups, starting with a full backup followed by zero or more incremental backups, that when combined, include the specified position. See more on [Restore Types](../overview/#restore-types) and on [Taking Incremental Backup](../creating-a-backup/#create-an-incremental-backup-with-vtctl).
 
-`v18` will supports restore to a given timestamp.

content/en/docs/18.0/user-guides/operating-vitess/backup-and-restore/overview.md

@@ -37,7 +37,7 @@ Generally speaking and on most workloads, the cost of a full backup is higher, a
 
 Full and incremental backups are expected to be interleaved. For example: one would create a full backup once per day, and incremental backups once per hour.
 
-Full backups are simply states of the database. Incremental backups, however, need to start with some point and end with some point. The common practice is for an incremental backup to continue from the point of the last good backup, which can be a full or incremental backup. An inremental backup in Vitess end at the point in time of execution.
+Full backups are simply states of the database. Incremental backups, however, need to start with some point and end with some point. The common practice is for an incremental backup to continue from the point of the last good backup, which can be a full or incremental backup. An inremental backup in Vitess ends at the point in time of execution.
 
 The identity of the tablet on which a full backup or an incremental backup is taken is immaterial. It is possible to take a full backup on one tablet and incremental backups on another. It is possible to take full backups on two different tablets. It is also possible to take incremental backups, independently, on two different tablets, even though the contents of those incremental backups overlaps. Vitess uses MySQL GTID sets to determine positioning and prune duplicates.