3.2. Восстановление кластера
Пред. НаверхГлава 3. Сценарии использованияНачало След.

3.2. Восстановление кластера #

3.2.1. Общие ограничения и особенности
3.2.2. Полное восстановление
3.2.3. Инкрементальное восстановление
3.2.4. Частичное восстановление
3.2.5. Выполнение восстановления на момент времени (PITR)
3.2.6. Удалённое восстановление

3.2.1. Общие ограничения и особенности #

Важно учитывать следующие ограничения и особенности процесса восстановления:

  • Переопределение расположения табличных пространств (tablespace remapping): при изменении расположения табличных пространств с помощью переопределения целевые каталоги должны существовать и быть доступны для записи.

  • Все родительские резервные копии в цепочке (от указанной копии до полной) должны присутствовать и быть доступны. Если отсутствует хотя бы одно звено цепочки, восстановление невозможно.

  • К восстановлению пригодны только резервные копии со статусом OK. Копии со статусами CORRUPT, ORPHAN, INVALID, ERROR или DELETED восстановить невозможно.

  • Резервная копия должна быть успешно завершена в момент создания. Прерванные или повреждённые копии восстановить невозможно. Использовать флаг --no-validate не рекомендуется, так как восстановление из повреждённой копии приведёт к несогласованному состоянию базы данных.

  • Для прохождения проверки резервная копия должна содержать не менее десяти файлов (защита от пустого каталога PGDATA или проблем с правами доступа).

  • Сегментация резервных копий: chunk_no каждого сегмента должен быть меньше total_chunks. Для успешного восстановления должны присутствовать все сегменты.

3.2.2. Полное восстановление #

Важно

Для полного восстановления каталог PGDATA должен быть полностью пуст. В противном случае восстановление завершится ошибкой.

Чтобы восстановить кластер баз данных из резервной копии, выполните команду restore как минимум со следующими параметрами:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра -i ид_резервной_копии

Здесь:

  • каталог_копий — каталог, в котором хранятся все файлы резервных копий и метаданные.

  • имя_экземпляра — имя экземпляра резервной копии кластера, который будет восстановлен.

  • ид_резервной_копии определяет, из какой резервной копии будет восстановлен кластер.

Если вы восстанавливаете копию ARCHIVE или выполняете восстановление PITR, pg_probackup3 создаёт файл конфигурации восстановления после копирования всех файлов данных в целевой каталог. Этот файл включает необходимые для восстановления параметры, за исключением пароля, заданного в primary_conninfo; если он требуется, его нужно дополнительно задать вручную или воспользоваться параметром --primary-conninfo. pg_probackup3 сохраняет эти параметры в файле probackup_recovery.conf в каталоге данных и подключает его в postgresql.auto.conf.

Если восстанавливалась копия типа STREAM, восстановление завершается сразу, и кластер возвращается в согласованное состояние на момент времени, в который была сделана резервная копия. Для копий типа ARCHIVE Postgres Pro воспроизводит все имеющиеся в архиве сегменты WAL, в результате чего восстанавливается самое последнее состояние кластера на текущей линии времени. Это поведение можно изменить, определив параметры точки восстановления для команды restore как описывается в Подразделе 3.2.5.

Если кластер, подлежащий восстановлению, содержит табличные пространства, pg_probackup3 по умолчанию восстанавливает их в исходные расположения. Чтобы сменить расположения табличных пространств, воспользуйтесь параметром --tablespace-mapping/-T. В противном случае при восстановлении кластера на том же сервере произойдёт ошибка, если эти табличные пространства будут использоваться, так как восстанавливаемые данные нужно будет записать в те же каталоги.

Используя параметр --tablespace-mapping/-T, вы должны задать абсолютные пути к старому и новому каталогу табличного пространства. Если путь содержит знак равно (=), экранируйте его обратной косой чертой. Данный параметр может указываться неоднократно для перемещения нескольких табличных пространств.

Примечание

Обратите внимание на синтаксис переопределения путей для нескольких табличных пространств: вместо нескольких флагов -T используйте один флаг с парами переопределения, разделёнными двоеточием. Например: 

pg_probackup3 restore -B каталог_копий --instance имя_экземпляра -D каталог_данных -j 4 -i ид_резервной_копии -T каталог_табл_пространства1=новый_каталог_табл_пространства1:каталог_табл_пространства2=новый_каталог_табл_пространства2

3.2.3. Инкрементальное восстановление #

Скорость восстановления резервной копии можно значительно увеличить, заменяя в существующем каталоге данных Postgres Pro только некорректные или изменённые страницы. Это можно реализовать, используя параметры инкрементального восстановления с командой restore.

Важно

Ограничения и особенности инкрементального восстановления:

  • При инкрементальном восстановлении, если каталог PGDATA пуст, но табличное пространство содержит данные, необходимо явно указать флаг --force для очистки табличного пространства.

  • При инкрементальном восстановлении файлы и каталоги, отсутствующие в новой резервной копии, автоматически удаляются, что при некорректном использовании может привести к потере данных.

  • Если каталог PGDATA и все табличные пространства пусты, режим автоматически переключается на полное восстановление.

Чтобы восстановить кластер баз данных из резервной копии в инкрементальном режиме, выполните команду restore со следующими параметрами:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра -D каталог_данных -I инкрементальный_режим

Здесь инкрементальный_режим может быть следующим:

  • CHECKSUM — прочитать все файлы данных в целевом каталоге, проверить заголовок и контрольную сумму каждой страницы и заменить только некорректные страницы, а также страницы, в которых контрольная сумма и LSN отличаются от значений в соответствующей странице в копии. Это самый простой и надёжный инкрементальный режим. Его рекомендуется использовать по умолчанию.

  • LSN — прочитать файл pg_control в каталоге данных, получить из него значения REDO LSN и REDO TLI, позволяющие определить точку в истории (точку сдвига), в которой состояние каталога данных сдвинулись с цепочки резервных копий. Если точка сдвига находится за пределами истории резервных копий, восстановление прерывается. Если же точка сдвига достижима, прочитываются все файлы данных в каталоге данных, проверяется заголовок и контрольная сумма на каждой странице, а затем заменяются только страницы с неверной контрольной суммой или с LSN, превышающим позицию точки сдвига. В этом режиме обеспечивается увеличенная скорость по сравнению с режимом CHECKSUM, но требуется выполнение двух условий. Во-первых, в целевом каталоге должны быть включены контрольные суммы, чтобы не произошло повреждения данных из-за изменения вспомогательных битов. Это условие будет проверяться перед инкрементальным восстановлением — в случае отсутствия контрольных сумм операция прерывается. Во-вторых, необходима синхронность файла pg_control с состоянием каталога данных. Это условие нельзя проверить в начале восстановления, так что гарантировать правильность информации в pg_control должен пользователь. Поэтому использовать режим LSN рекомендуется не во всех ситуациях, например, он противопоказан, когда файл pg_control повреждён или его содержимому нельзя доверять: после выполнения pg_resetxlog, после восстановления из копии без процедуры воспроизведения журнала и т. д.

  • NONE — обычное восстановление без инкрементальных оптимизаций.

Вне зависимости от выбранного инкрементального режима, pg_probackup3 будет проверять, что с заданным целевым каталогом не работает процесс postmaster и значения system-identifier в целевом экземпляре и копии совпадают.

Пример использования инкрементального восстановления с табличным пространством в режиме CHECKSUM:

================================================================================================================================
Instance Version ID      End time                 Mode  WAL Mode TLI Duration Data WAL Zalg Zratio Start LSN  Stop LSN   Status
================================================================================================================================
inst     17      1-full  2025-08-05 16:14:10+0700 FULL  STREAM   1   1s       47MB -   none 1.46   0/A3000028 0/A3000160 OK
inst     17      1-delta 2025-08-05 16:14:33+0700 DELTA STREAM   1   1s       21MB -   none 3.18   0/A5000028 0/A5000160 OK
inst     17      2-delta 2025-08-05 16:14:37+0700 DELTA STREAM   1   0ms      21MB -   none 3.18   0/A6000028 0/A6000160 OK

backup_user@backup_host:~$ ./pg_probackup3 restore -D /mnt/node -B /mnt/b3b --instance=inst -I checksum --backup-id 2-delta -T /mnt/ts1=/mnt/ts2 --threads=1
[2025-08-05 16:20:38.061117] [264669] [0x79693fc1a4c0] [info] command: ./pg_probackup3 restore -D /mnt/node -B /mnt/backups --instance=inst -I checksum --backup-id 2-delta -T /mnt/ts1=/mnt/ts2 --threads=1
[2025-08-05 16:20:38.061244] [264669] [0x79693fc1a4c0] [info] execute command: 'restore', instance 'inst', backup_id '2-delta'
[2025-08-05 16:20:38.061855] [264669] [0x79693fc1a4c0] [info] Start validate 2-delta ...
[2025-08-05 16:20:38.065368] [264669] [0x79693d5a66c0] [info] Validating backup 1-full chunk #0 out of 8
[2025-08-05 16:20:38.088840] [264669] [0x79693d5a66c0] [info] Validating backup 1-full chunk #1 out of 8
[2025-08-05 16:20:38.112253] [264669] [0x79693d5a66c0] [info] Validating backup 1-full chunk #2 out of 8
[2025-08-05 16:20:38.193395] [264669] [0x79693d5a66c0] [info] Validating backup 1-full chunk #3 out of 8
[2025-08-05 16:20:38.213982] [264669] [0x79693d5a66c0] [info] Validating backup 1-full chunk #4 out of 8
[2025-08-05 16:20:38.235532] [264669] [0x79693d5a66c0] [info] Validating backup 1-full chunk #5 out of 8
[2025-08-05 16:20:38.256768] [264669] [0x79693d5a66c0] [info] Validating backup 1-full chunk #6 out of 8
[2025-08-05 16:20:38.278902] [264669] [0x79693d5a66c0] [info] Validating backup 1-full chunk #7 out of 8
[2025-08-05 16:20:38.300380] [264669] [0x79693fc1a4c0] [info] Validate time 235ms
[2025-08-05 16:20:38.301628] [264669] [0x79693d5a66c0] [info] Validating backup 1-delta chunk #0 out of 8
[2025-08-05 16:20:38.305281] [264669] [0x79693d5a66c0] [info] Validating backup 1-delta chunk #1 out of 8
[2025-08-05 16:20:38.368129] [264669] [0x79693d5a66c0] [info] Validating backup 1-delta chunk #2 out of 8
[2025-08-05 16:20:38.371719] [264669] [0x79693d5a66c0] [info] Validating backup 1-delta chunk #3 out of 8
[2025-08-05 16:20:38.375494] [264669] [0x79693d5a66c0] [info] Validating backup 1-delta chunk #4 out of 8
[2025-08-05 16:20:38.379185] [264669] [0x79693d5a66c0] [info] Validating backup 1-delta chunk #5 out of 8
[2025-08-05 16:20:38.383215] [264669] [0x79693d5a66c0] [info] Validating backup 1-delta chunk #6 out of 8
[2025-08-05 16:20:38.386733] [264669] [0x79693d5a66c0] [info] Validating backup 1-delta chunk #7 out of 8
[2025-08-05 16:20:38.390220] [264669] [0x79693fc1a4c0] [info] Validate time 89ms
[2025-08-05 16:20:38.391428] [264669] [0x79693d5a66c0] [info] Validating backup 2-delta chunk #0 out of 8
[2025-08-05 16:20:38.395259] [264669] [0x79693d5a66c0] [info] Validating backup 2-delta chunk #1 out of 8
[2025-08-05 16:20:38.399093] [264669] [0x79693d5a66c0] [info] Validating backup 2-delta chunk #2 out of 8
[2025-08-05 16:20:38.402872] [264669] [0x79693d5a66c0] [info] Validating backup 2-delta chunk #3 out of 8
[2025-08-05 16:20:38.405935] [264669] [0x79693d5a66c0] [info] Validating backup 2-delta chunk #4 out of 8
[2025-08-05 16:20:38.468891] [264669] [0x79693d5a66c0] [info] Validating backup 2-delta chunk #5 out of 8
[2025-08-05 16:20:38.472336] [264669] [0x79693d5a66c0] [info] Validating backup 2-delta chunk #6 out of 8
[2025-08-05 16:20:38.475977] [264669] [0x79693d5a66c0] [info] Validating backup 2-delta chunk #7 out of 8
[2025-08-05 16:20:38.479477] [264669] [0x79693fc1a4c0] [info] Validate time 88ms
[2025-08-05 16:20:38.479859] [264669] [0x79693fc1a4c0] [info] INFO: Backup 2-delta is valid
[2025-08-05 16:20:38.479992] [264669] [0x79693fc1a4c0] [info] Start restore of backup 2-delta into /mnt/node
[2025-08-05 16:20:38.481239] [264669] [0x79693fc1a4c0] [info] Backup 1-delta is chosen as shiftpoint, its Stop LSN will be used as shift LSN
[2025-08-05 16:20:38.483006] [264669] [0x79693d5a66c0] [info] Restoring 2-delta chunk #0 out of 8
[2025-08-05 16:20:38.532219] [264669] [0x79693d5a66c0] [info] Restoring 2-delta chunk #1 out of 8
[2025-08-05 16:20:38.569631] [264669] [0x79693d5a66c0] [info] Restoring 2-delta chunk #2 out of 8
[2025-08-05 16:20:38.608792] [264669] [0x79693d5a66c0] [info] Restoring 2-delta chunk #3 out of 8
[2025-08-05 16:20:38.633202] [264669] [0x79693d5a66c0] [info] Restoring 2-delta chunk #4 out of 8
[2025-08-05 16:20:38.733030] [264669] [0x79693d5a66c0] [info] Restoring 2-delta chunk #5 out of 8
[2025-08-05 16:20:38.764890] [264669] [0x79693d5a66c0] [info] Restoring 2-delta chunk #6 out of 8
[2025-08-05 16:20:38.804717] [264669] [0x79693d5a66c0] [info] Restoring 2-delta chunk #7 out of 8
[2025-08-05 16:20:38.839108] [264669] [0x79693fc1a4c0] [info] Restore time 356ms
[2025-08-05 16:20:38.839256] [264669] [0x79693fc1a4c0] [info] Removing redundant files in destination directory
[2025-08-05 16:20:38.848171] [264669] [0x79693d5a66c0] [info] Restoring 1-delta chunk #0 out of 8
[2025-08-05 16:20:38.860342] [264669] [0x79693d5a66c0] [info] Restoring 1-delta chunk #1 out of 8
[2025-08-05 16:20:38.918134] [264669] [0x79693d5a66c0] [info] Restoring 1-delta chunk #2 out of 8
[2025-08-05 16:20:38.929649] [264669] [0x79693d5a66c0] [info] Restoring 1-delta chunk #3 out of 8
[2025-08-05 16:20:38.942811] [264669] [0x79693d5a66c0] [info] Restoring 1-delta chunk #4 out of 8
[2025-08-05 16:20:38.954785] [264669] [0x79693d5a66c0] [info] Restoring 1-delta chunk #5 out of 8
[2025-08-05 16:20:38.970253] [264669] [0x79693d5a66c0] [info] Restoring 1-delta chunk #6 out of 8
[2025-08-05 16:20:38.983111] [264669] [0x79693d5a66c0] [info] Restoring 1-delta chunk #7 out of 8
[2025-08-05 16:20:38.995516] [264669] [0x79693fc1a4c0] [info] Restore time 148ms
[2025-08-05 16:20:38.997560] [264669] [0x79693d5a66c0] [info] Restoring 1-full chunk #0 out of 8
[2025-08-05 16:20:39.032484] [264669] [0x79693d5a66c0] [info] Restoring 1-full chunk #1 out of 8
[2025-08-05 16:20:39.062668] [264669] [0x79693d5a66c0] [info] Restoring 1-full chunk #2 out of 8
[2025-08-05 16:20:39.134805] [264669] [0x79693d5a66c0] [info] Restoring 1-full chunk #3 out of 8
[2025-08-05 16:20:39.160183] [264669] [0x79693d5a66c0] [info] Restoring 1-full chunk #4 out of 8
[2025-08-05 16:20:39.189998] [264669] [0x79693d5a66c0] [info] Restoring 1-full chunk #5 out of 8
[2025-08-05 16:20:39.219022] [264669] [0x79693d5a66c0] [info] Restoring 1-full chunk #6 out of 8
[2025-08-05 16:20:39.249562] [264669] [0x79693d5a66c0] [info] Restoring 1-full chunk #7 out of 8
[2025-08-05 16:20:39.279275] [264669] [0x79693fc1a4c0] [info] Restore time 282ms
[2025-08-05 16:20:39.280742] [264669] [0x79693fc1a4c0] [info] INFO: Restore of backup 2-delta completed.

3.2.4. Частичное восстановление #

Можно восстанавливать определённые базы данных с помощью параметров частичного восстановления с командой restore. Ниже представлены все возможные варианты частичного восстановления.

Важно

Следующие особенности важно учитывать при любом методе частичного восстановления:

  • После успешного запуска кластера Postgres Pro восстановленные определения исключённых баз данных можно удалить с помощью команды DROP DATABASE.

  • Чтобы максимально быстро разделить один кластер, содержащий несколько баз данных, на разные кластеры, можно выполнить частичное восстановление исходного кластера в виде ведомого, передав ключ --restore-as-replica для определённых баз данных.

  • Базы template0 и template1 восстанавливаются всегда.

3.2.4.1. Частичное восстановление по имени #

Если вы настроили частичное восстановление прежде, чем создавать резервные копии, вы можете восстанавливать отдельные базы данных, используя параметры --db-include-name и --db-exclude-name.

Важно

Для восстановления баз данных по имени резервная копия должна содержать карту баз данных (database map). Без карты фильтрация возможна только по OID.

Чтобы восстановить только определённые базы данных, выполните команду restore со следующими параметрами:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-include-name=имя_бд

Чтобы исключить одну или несколько баз из числа восстанавливаемых, используйте параметр --db-exclude-name:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-exclude-name=имя_бд

Параметры --db-include-name и --db-exclude-name можно указывать многократно, но они не могут использоваться вместе. Например, чтобы восстановить базы данных db1 и db2, выполните следующую команду:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-include-name=db1 --db-include-name=db2

Чтобы исключить те же базы данных, что и в предыдущем примере, выполните:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-exclude-name=db1 --db-exclude-name=db2

3.2.4.2. Частичное восстановление по OID #

Можно восстанавливать определённые базы данных без дополнительной подготовки (в отличие от частичного восстановления по имени) с помощью параметров --db-include-oid и --db-exclude-oid.

Чтобы восстановить только определённые базы данных, выполните команду restore со следующими параметрами:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-include-oid=dboid

Примечание

При восстановлении обрабатываются только WAL-записи для включённых баз данных, остальные игнорируются, что ускоряет операцию.

Чтобы исключить одну или несколько баз из числа восстанавливаемых, используйте параметр --db-exclude-oid:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-exclude-oid=dboid

Параметры --db-include-oid и --db-exclude-oid можно указывать многократно, но они не могут использоваться вместе. Например, чтобы восстановить только базы данных db1 (OID dboid1) и db2 (OID dboid2), выполните следующую команду:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-include-oid=dboid1 --db-include-oid=dboid2

Чтобы исключить те же базы данных, что и в предыдущем примере, выполните:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-exclude-oid=dboid1 --db-exclude-oid=dboid2

3.2.5. Выполнение восстановления на момент времени (PITR) #

Вы можете восстановить состояние кластера на любой момент времени (до заданной точки восстановления), используя с командой restore параметры точки восстановления.

Перед началом восстановления на момент времени убедитесь, что выполнены следующие условия:

  • Вы настроили непрерывную архивацию WAL с параметром wal_level, установленным в значение replica, до создания резервных копий.

  • Осуществляется регулярное создание полных и инкрементальных резервных копий с помощью pg_probackup3.

Для восстановления на момент времени может использоваться копия типа STREAM или ARCHIVE при условии, что WAL-архив содержит непрерывную последовательность сегментов от момента создания резервной копии до целевой точки восстановления.

Для восстановления состояния кластера на определённый момент времени выполните приведённые ниже действия, подставляя свои значения.

  1. Остановите сервер:

    pg_ctl stop -D /путь/к/базе_данных/data

  2. Удалите каталог данных (PGDATA):

    rm -rf /путь/к/базе_данных/data
mv -f /путь/к/базе_данных/logs/pg_logfile.log /tmp/demo/logs/pg_logfile.log.old

    Это необязательный шаг, так как для восстановления может использоваться другой каталог.

    Рекомендуется сохранять файл с журналами в целях диагностики.

  3. Выполните команду restore со следующими параметрами:

    pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --recovery-target-time="2024-04-10 18:18:26+03" --recovery-target-action=promote

  4. Запустите сервер:

    pg_ctl start -D /путь/к/базе_данных/data

По завершении восстановления новый экземпляр будет автоматически повышен до ведущего, и будет создана новая линия времени (timeline).

Также можно извлечь конкретный сегмент из архива для ручного восстановления на момент времени или в целях диагностики, выполнив команду archive-get с параметром --wal-file-path, содержащим абсолютный путь к целевому файлу:

pg_probackup3 archive-get -B /backup --instance=main --wal-file-path=/var/lib/pgsql/data/pg_wal/RECOVERYXLOG --wal-file-name=000000010000000000000001

Другие поддерживаемые методы PITR описаны в разделе «Параметры точки восстановления».

3.2.6. Удалённое восстановление #

Удалённое восстановление в pg_probackup3 — это функциональность, позволяющая восстанавливать резервные копии напрямую на удалённый сервер без необходимости копировать файлы архива вручную. Такой подход существенно сокращает время восстановления и количество ручных операций при аварийном восстановлении, миграции или автоматическом развёртывании.

Функциональность удалённого восстановления состоит из следующих основных компонентов:

  • Команда send-backup в утилите pg_probackup3 для передачи данных через указанный порт на удалённый сервер с использованием многопоточности.

  • Утилита pgpro_backupstream, запускаемая вручную на удалённом сервере, для получения, распаковки и восстановления данных.

Для выполнения удалённого восстановления необходимо соблюдать следующие условия:

  • В локальной системе:

    • Должны быть установлены утилита pg_probackup3 и библиотека libpgprobackup.

    • Должен быть обеспечен доступ к каталогу резервных копий.

  • В удалённой системе:

    • Должна быть установлена утилита pgpro_backupstream.

      Примечание

      pgpro_backupstream запускается вручную.

    • Каталог PGDATA должен быть пустым и открытым для записи.

      Примечание

      На данный момент инкрементальное восстановление в удалённом режиме не поддерживается.

    • Выбранный порт должен быть открыт и доступен для входящих подключений.

Чтобы восстановить экземпляр на удалённый сервер, выполните следующие шаги:

  1. В локальной системе выполните команду send-backup через утилиту pg_probackup3, чтобы отправить данные резервной копии на удалённый сервер по указанному порту:

    pg_probackup3 send-backup -B каталог_копий --instance=имя_экземпляра -i ид_резервной_копии -p порт -h сервер [--no-merge] [параметры_удалённого_архива_wal]

    Флаг --no-merge отключает слияние цепочки резервных копий перед передачей данных. В противном случае цепочка резервных копий будет автоматически объединена во временный файл, который удалится после завершения передачи.

    Если архив WAL находится на отдельном сервере, укажите параметры доступа к нему — --archive-host, --archive-port и --archive-user (параметры удалённого архива WAL). Команда send-backup будет получать необходимые WAL-файлы непосредственно из удалённого архива.

  2. В удалённой системе запустите команду restore через утилиту pgpro_backupstream для приёма и восстановления данных:

    pgpro_backupstream restore -D путь_для_восстановления [-p порт]

    Если порт не указан, используется STDIN.

Важно

Запустите утилиту pgpro_backupstream в удалённой системе до того, как начать передачу данных с помощью команды send-backup.

Пред. Наверх След.
3.1. Создание резервной копии Начало 3.3. Управление каталогом резервных копий

Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера