Sync docs from Discourse (#633)

Co-authored-by: GitHub Actions <41898282+github-actions[bot]@users.noreply.github.com>

Author: github-actions[bot]

docs/how-to/h-restore-backup.md

@@ -15,10 +15,14 @@ To restore a backup that was made from the a *different* cluster, (i.e. cluster
 - Access to S3 storage
 - [Have configured settings for S3 storage](/t/9894)
 - [Have existing backups in your S3-storage](/t/9896)
+- Point-in-time recovery requires the following MySQL charm revisions:
+  * 369+ for `arm64`
+  * 368+ for `amd64`
 
 ## Summary
 
 * [List backups](#list-backups)
+* [Point-in-time recovery](#point-in-time-recovery)
 * [Restore backup](#restore-backup)
 
 ---
@@ -38,11 +42,30 @@ This should show your available backups
       YYYY-MM-DDTHH:MM:SSZ  | physical     | finished
 ```
 
+## Point-in-time recovery
+
+Point-in-time recovery (PITR) is a MySQL feature that enables restorations to the database state at specific points in time. The feature is enabled by default when there's a working relation with S3 storage.
+
+
 ## Restore backup
 
 To restore a backup from that list, run the `restore` command and pass the `backup-id` to restore:
  ```shell
 juju run mysql/leader restore backup-id=YYYY-MM-DDTHH:MM:SSZ
 ```
 
-Your restore will then be in progress.
+Your restore will then be in progress.
+
+However, if the user needs to restore to a specific point in time between different backups (e.g. to restore only specific transactions made between those backups), they can use the restore-to-time parameter to pass a timestamp related to the moment they want to restore.
+
+ ```shell
+juju run mysql/leader restore restore-to-time="YYYY-MM-DD HH:MM:SS"
+```
+
+Your restore will then be in progress.
+
+It’s also possible to restore to the latest point from a specific timeline by passing the ID of a backup taken on that timeline and restore-to-time=latest when requesting a restore:
+
+ ```shell
+juju run mysql/leader restore restore-to-time=latest
+```

docs/reference/r-releases.md

@@ -16,6 +16,7 @@ For a given release, this table shows:
 
 | Release | MySQL version | Juju version | [TLS encryption](/t/9898)* | [COS monitoring](/t/9900) | [Minor version upgrades](/t/11748) | [Cross-regional async replication](/t/14169) |
 |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
+| [366], [367] | 8.0.41 | `3.4.3+` | ![check] | ![check] | ![check] | ![check] |
 | [312], [313] | 8.0.39 | `3.4.3+` | ![check] | ![check] | ![check] | ![check] |
 | [240] | 8.0.36 | `3.4.3+` | ![check] | ![check] | ![check] | ![check] |
 | [196] | 8.0.34 | `3.1.6+` |  | ![check] | ![check] |  |
@@ -34,14 +35,22 @@ Several [revisions](https://juju.is/docs/sdk/revision) are released simultaneous
 > If you deploy a specific revision, **you must make sure it matches your base and architecture** via the tables below or with [`juju info`](https://juju.is/docs/juju/juju-info)
 
 
+### Release 366-367
+
+| Revision | amd64 | arm64 | Ubuntu 22.04 LTS
+|:--------:|:-----:|:-----:|:-----:|
+|[366]  |![check] | | ![check]  |
+|[367] |  | ![check]| ![check] |
+
+[details=Older releases]
+
 ### Release 312-313
 
 | Revision | amd64 | arm64 | Ubuntu 22.04 LTS
 |:--------:|:-----:|:-----:|:-----:|
 |[313]  |![check] | | ![check]  |
 |[312] |  | ![check]| ![check] |
 
-[details=Older releases]
 
 ### Release 240
 
@@ -69,6 +78,8 @@ Several [revisions](https://juju.is/docs/sdk/revision) are released simultaneous
 
 <!-- LINKS -->
 
+[367]: https://github.com/canonical/mysql-operator/releases/tag/rev366
+[366]: https://github.com/canonical/mysql-operator/releases/tag/rev366
 [313]: https://github.com/canonical/mysql-operator/releases/tag/rev312
 [312]: https://github.com/canonical/mysql-operator/releases/tag/rev312
 [240]: https://github.com/canonical/mysql-operator/releases/tag/rev240