@Nic77

Добрый день !
Поймали шифровальщика, зашифровал все в том числе и архивы.
Я периодически сбрасываю к себе базы. Сбросил 10.09 полностью папку с постгрессом. и 04.10 сбросил папку base (не в курсе был что надо всю папку data) на всякий случай.
Сервак свежий еще был в процессе подготовки к работе, но данные уж забивались. Киберпротект поставили но он сходу не завелся.

Поставил новый postresql 16 тот же дистрибутив что был. Подсунул DATE от 10.09. Все ок базы поднялись, закинул туда 5 баз c oid из свежей копии. И тут какая то ерунда начинается. Вроде первые таблички начинают открываться. Потом на очередной таблице ошибка типа такой

WARNING: could not write block 0 of base/18042/2619_vm

xlog flush request 28/9C496F20 is not satisfied --- flushed only to 23/32A580A8
��������: writing block 0 of relation base/18042/2619_vm

И перестает отрываться вообще все.

Можно что то сделать ?

Добавлено через 4 часа 6 минут
хм дополню, жму несколько раз, с 4-5 раза табличка открывается без ошибки, потом опять ошибка такая

0

@grgdvo

base без global это практически приговор (((

0

@Nic77

global есть месячной свежести, и я смотрю его в нем изменения все вообще 2 месячной давности, когда базы создавались, и как то понимается мне что если за месяц до этого в нем ничего не менялось кроме pg_control , то и за этот месяц вряд ли что поменялось
И базы даже начинают открываться но как то нестабильно с 3-4-5-6-7-8 попытки получается табличку открыть в pgadmin

0

@grgdvo

pg_control самый главный файл.
Попробуйте следующее. Во-первых сделайте еще одну копию тех директорий, который Вам удалось спасти.
Только именно тех данных, которые у вас сохранились, а не тех, над которыми Вы уже проводили какие-то эксперименты.
Объедините эти данные в каком-нибудь третьем месте с сделайте pg_resetwal -n -D /my.corrupted.data/...
Это даст вам отчет о том, что удалось собрать из Ваших данных, может быть найдутся какие-то ошибки, которые дальше надо будет думать, как исправлять.
Если ошибок не обнаружится и Вы не увидите ничего для Вас интересного, то попробуйте просто сделать pg_resetwal - это необратимые изменения в директории данных (копия данных у Вас должна остаться нетронутой!!!).
Может быть после этого что-то станет запускаться и может быть даже без ошибок, связанных с некорректным LSN

0

@Nic77

Все вышеперечисленное выполнял в разных вариантах. Помогает буквально на 2-3 таблички, на 4-5 запрос делаю и опять те же ошибки. Копии само собой сделал на каждом шаге. Поведение вообще странное у постгресс, данные есть и есть в полном объеме, но нельзя ничего сделать как так ? В других субд (оракл, ms sql) такая ситуация априори не может быть. Если есть файлы с данными остальное хоть все убей, можно восстановить.

0

@grgdvo

Я точно не знаю, что там в оракле.
Но полагаю, что если от ораклового файла оставить половину, то тоже ничего хорошего не получится.
В Постгресе global + base + pg_wal составляют единое целое (в общем-то как и другие поддиректории),
просто разбито на поддиректории по виду данных. Поэтому (((

У вас ошибка про видимость данных, утеряна информация о видимости строк (vm = visibility map)
VM-файл трогает vacuum. Попробуйте поиграться командой/утилитой vacuumdb
Может переписать и зафризить все записи.
К сожалению это может привести к ошибкам.
Вы вдруг неожиданно увидите удаленные записи или какие-то старые записи.
Но хотя бы не будет ошибок доступа к таблицам и можно будет что-то дальше делать.

Удачи

0