refactor

Signed-off-by: SK Ali Arman <[email protected]>

docs/guides/mysql/pitr/restic/archiver.md

@@ -214,9 +214,14 @@ retention-policy-mysql-archiver-manifest-backup-1733120326l79mb   0/1     Comple
 
 `mysql-sidekick` is responsible for uploading binlog files
 
-The pod mysql-archiver-full-backup-1733120326-4n8nd is responsible for creating the base backup of MySQL. 
+`mysql-archiver-full-backup-1733120326-4n8nd` is responsible for creating the base backup of MySQL. 
+
 `mysql-archiver-manifest-backup-1733120326-9gw4f` is the pod of the manifest backup related to MySQL object.
 
+`retention-policy-mysql-archiver-full-backup-1733120326-7rx9t` will automatically clean up previous full-backup snapshots according to the rules defined in the `mysql-retention-policy` custom resource (CR).
+
+`retention-policy-mysql-archiver-manifest-backup-1733120326l79mb` will automatically clean up previous manifest-backup snapshots according to the rules specified in the `mysql-retention-policy` custom resource (CR).
+
 ### Validate BackupConfiguration and BackupSession
 
 ```bash
@@ -230,11 +235,10 @@ $ kubectl get backupsession -n demo
 NAME                                        INVOKER-TYPE          INVOKER-NAME     PHASE       DURATION   AGE
 mysql-archiver-full-backup-1733120326       BackupConfiguration   mysql-archiver   Succeeded   50s        14m
 mysql-archiver-manifest-backup-1733120326   BackupConfiguration   mysql-archiver   Succeeded   25s        14m
-                                      1Gi           longhorn-snapshot-vsc   snapcontent-735e97ad-1dfa-4b70-b416-33f7270d792c   2m5s           2m5s
 ```
 
 ## data insert and switch wal
-After each and every wal switch the wal files will be uploaded to backup storage
+After each and every binlog switch the binlog files will be uploaded to backup storage
 
 ```bash
 $ kubectl exec -it -n demo  mysql-0 -- bash
@@ -286,7 +290,7 @@ mysql> select count(*) from demo_table;
 
 ## Point-in-time Recovery
 Point-In-Time Recovery allows you to restore a MySQL database to a specific point in time using the archived transaction logs. This is particularly useful in scenarios where you need to recover to a state just before a specific error or data corruption occurred.
-Let's say accidentally our dba drops the the table tab_1 and we want to restore.
+Let's say accidentally our db drops the the table `demo_table` and we want to restore that.
 
 ```bash
 $ kubectl exec -it -n demo  mysql-0 -- bash
@@ -296,10 +300,9 @@ mysql> drop table demo_table;
 mysql> flush logs;
 
 ```
-We can't restore from a full backup since at this point no full backup was perform. so we can choose a specific time in which time we want to restore.We can get the specfice time from the wal that archived in the backup storage . Go to the binlog file and find where to store. You can parse binlog-files using  `mysqlbinlog`.
+We can't restore from a full backup since at this point no full backup was perform. so we can choose a specific time in which time we want to restore.We can get the specific time from the binlog that archived in the backup storage . Go to the binlog file and find where to store. You can parse binlog-files using  `mysqlbinlog`.
 
-
-For the demo I will use the previous time we get form `select now()`
+For the demo I will use the previous time we get from `select now()`
 
 ```bash 
 mysql> select now();
@@ -366,7 +369,7 @@ mysql.kubedb.com/mysql           8.2.0     Ready    32m
 mysql.kubedb.com/restore-mysql   8.2.0     Ready    2m53s
 ```
 
-**Validating data on Restored MySQL**
+**Validating Data on Restored MySQL**
 
 ```bash
 $ kubectl exec -it -n demo restore-mysql-0 -- bash
@@ -406,7 +409,8 @@ The base backup and binlog files are restored exclusively on pod-0. Other replic
 
 The base backup and binlog files are restored on pod-0. The data is then copied from pod-0's data directory to the data directories of other replicas using file system copy. Once the data transfer is complete, the group replication process begins.
 
-Choose the replication strategy that best fits your restoration and replication requirements.
+Choose the replication strategy that best fits your restoration and replication requirements. n this demonstration, we have used the sync replication strategy.
+
 To cleanup the Kubernetes resources created by this tutorial, run:
 
 ```bash