[EDP-DDM-32667] Added fixes to postgres-backup-restore.adoc

Change-Id: I522b53f3105f287e977f71f421d4c7f45dde5d2a
(cherry picked from commit 712bc723e7e4c1d3a898eaa4665fed9185dafe13)
(cherry picked from commit 7e8dfb09d0a90a33974533e21bf8b4c72e56ef7c)
(cherry picked from commit 935d3fcfc490e5b224b9ad82d97973700185ead7)

docs/ua/modules/admin/pages/backup-restore/postgres-backup-restore.adoc

@@ -29,8 +29,6 @@ Postgres Operator від Crunchy Data (PGO), який використовуєт
 * Виконання «відновлення на певний момент часу» (PITR)
 * Клонування даних у новий екземпляр БД
 
-* та інше.
-
 == Налаштування резервного копіювання
 За замовчанням операційний та аналітичний кластери Postgres налаштовані таким чином, що вони постійно архівують журнал попереднього запису (WAL) та роблять повну резеврну копію раз на добу. Політикою збереження налаштовано зберігання однієї повної копії, таким чином після створення нової копії pgBackRest очистить попередню копію та пов’язані з нею файли WAL.
 
@@ -109,23 +107,31 @@ spec:
 Наприклад, для operational кластера  ми можемо виконати таку команду, щоб запустити одноразове резервне копіювання:
 [source,bash]
 ----
-kubectl annotate -n postgres-operator postgrescluster operational \
+kubectl annotate -n <registry-name> postgrescluster operational \
   postgres-operator.crunchydata.com/pgbackrest-backup="$(date)"
 ----
+
+TIP: де `<registry-name>` -- назва вашого реєстру/namespace.
+
 PGO виявить цю анотацію та створить нове одноразове завдання резервного копіювання!
 
 Якщо ви збираєтеся робити одноразові резервні копії з подібними параметрами в майбутньому, ви можете залишити їх у специфікації; просто оновіть анотацію до іншого значення під час наступного резервного копіювання.
 
 Щоб повторно запустити наведену вище команду, вам потрібно буде додати помітку `--overwrite`, щоб можна було оновити значення анотації, тобто.
 [source,bash]
 ----
-kubectl annotate -n postgres-operator postgrescluster operational --overwrite \
+kubectl annotate -n <registry-name> postgrescluster operational --overwrite \
   postgres-operator.crunchydata.com/pgbackrest-backup="$(date)"
 ----
+
+TIP: де `<registry-name>` -- назва вашого реєстру/namespace.
+
 == Відновлення
 
 === Відновлення на момент часу чи на конкретну резервну копію
-Для того щоб відновити стан БД на потрібну дату і час в першу чергу в секцію `spec.backups.pgbackrest` потрібно додати наступне:
+
+Щоб відновити стан БД на потрібну дату і час, найперше, потрібно у секцію `spec.backups.pgbackrest` додати наступне:
+
 [source,yaml]
 ----
 spec:
@@ -136,9 +142,11 @@ spec:
         repoName: repo1
         options:
         - --type=time
-        - --target="2022-06-09 14:15:11-04"
+        - --target="2022-06-09 14:15:11"
 ----
-де `--target` цільовий час відновлення PITR. Прикладом цілі відновлення є `2022-06-09 14:15:11-04`.
+де `--target` цільовий час відновлення PITR. Прикладом часу відновлення є `2022-06-09 14:15:11`.
+
+NOTE: Час відновлення вказується за UTC.
 
 Щоб відновити базу на конкретну резервну копію, в секцію `spec.backups.pgbackrest` треба додати наступне:
 [source,yaml]
@@ -153,14 +161,20 @@ spec:
         - --type=immediate
         - --set=20220602-073427F_20220602-073507I
 ----
-де `--set` назва цільової резервної копії. Список доступних резервних копій можно переглянути в бакеті s3 резервного сховища, або виконавши команду pgbackrest info --stanza=db в консолі пода БД.
+де `--set` назва цільової резервної копії. Список доступних резервних копій можно переглянути в бакеті s3 резервного сховища, або виконавши команду `pgbackrest info --stanza=db` в консолі поду БД.
+
+IMPORTANT: Усі дані, створені після цільової дати відновлення (`--target="2022-06-09 14:15:11"`) і до моменту початку процесу відновлення, будуть втрачені. Тому обов'язково потрібно врахувати це перед початком відновлення.
+
+Щоб ініціювати відновлення, ви повинні додати анотацію `postgres-operator.crunchydata.com/pgbackrest-restore` наступним чином:
 
-Тепер, щоб ініціювати відновлення, ви повинні додати анотацію `postgres-operator.crunchydata.com/pgbackrest-restore` наступним чином:
 [source,bash]
 ----
-kubectl annotate -n postgres-operator postgrescluster operational --overwrite \
-  postgres-operator.crunchydata.com/pgbackrest-restore=id1
+kubectl annotate -n <registry-name> postgrescluster operational --overwrite \
+  postgres-operator.crunchydata.com/pgbackrest-restore="$(date)"
 ----
+
+TIP: де `<registry-name>` -- назва вашого реєстру/namespace.
+
 Після завершення відновлення додане налаштування можна вимкнути:
 
 [source,yaml]
@@ -174,9 +188,9 @@ spec:
 
 [IMPORTANT]
 ====
-Всі ці операції потрібно провести як на операційній так і на аналітичній базі данних.
+Всі ці операції потрібно провести як на операційній, так і на аналітичній базі даних.
 
-Для відновлення відповідності данних між операційною та аналітичною БД виконайте <<Узгодження данних на аналітичному кластері>>
+Для відновлення відповідності даних між операційною та аналітичною БД виконайте <<Узгодження данних на аналітичному кластері>>
 ====
 
 === Клонування з резервної копії