LINUX.ORG.RU
решено ФорумAdmin

Достать данные из SQL

 , ,


0

2

Сдох SSD на котором крутилась postgresql база.

Данные я вытащил ddrescue. Положил на соседний живой диск и запустил с ними postgres.

Но по итогу при любом запросе к базе ERROR: could not open file "base/16385/2689": No such file or directory

Даже структуру посмотреть не даёт. \dt

Есть у кого-то идеи как можно вытянуть данные?

Мне известна примерная структура таблиц до возникновения проблемы.

Бэкапы никто не делал.

Файла "base/16385/2689" в ФС нету.

★★

Ответ на: комментарий от anonymous

Данные я вытащил ddrescue.

Это образ раздела на котором в том числе /var/lib/postgresql/...

С копией этих данных я и запустил postgres.

Но обратиться к данным не могу. На любой запрос, даже \dt получаю

ERROR: could not open file "base/16385/2689": No such file or directory

Flotsky ★★
() автор топика
Ответ на: комментарий от anonymous

Это когда SQLite научилась в базы из-под постгреса?

anonymous
()
Ответ на: комментарий от Zhbert

Было несколько последовательных отключений света.

Потом xz compressed data is corrupt system halted

Из SysReqCD под chroot пришёл к выводу что побились бинарники или библиотеки ряда утилит.

Некоторые текстовые файлы похудели в размере и вместо текста стали содержать кракозябры.

Диск поменял, систему переставил, а данные я из воздуха не возьму.

Flotsky ★★
() автор топика
Ответ на: комментарий от Flotsky

а данные я из воздуха не возьму.

Золотые слова. Собственно это и есть ответ.

anonymous
()
Ответ на: комментарий от Flotsky

а данные я из воздуха не возьму.

Ну что я тебе могу сказать… Надо было делать бэкапы.

Zhbert ★★★★★
()
Ответ на: комментарий от anonymous

Копай здесь: https://pgconf.ru/2019/242086

Хм. Навёл на мысль.

base/16385 это интересующая меня база.

т.к. я знаю примерно что там за данные и как они лежат смог определить соответствие файл - таблица

Итого могу выковырять построчно данные. strings $file | less

*Мне хватило чтобы достать то что нужно.

*Да догадываюсь что это не гарантирует правильность данных.

Flotsky ★★
() автор топика

Сейчас случайно набрел как раз на текст для тебя

Одной из очевидных задач обслуживания СУБД является регулярное создание резервных копий данных. При отсутствии свежей резервной копии у вас не будет шанса восстановить систему после катастрофы (сбой диска, пожар, удаление важной таблицы по ошибке и т. д.). Механизмы резервного копирования и восстановления в PostgreSQL детально рассматриваются в Главе 25.

https://postgrespro.ru/docs/postgresql/9.6/maintenance

anonymous
()
Ответ на: комментарий от Zhbert

Как сдох? Они обычно в ридонли переходят, но читается как обычно все.


ахахаха. просто АХАХАХАХА

zgen ★★★★★
()

Если база не сильно большая - спроси у ваших разрабов. Иногда народ себе дамп делает, чтобы локально с ним работать - может у кого завалялся, пусть и старый. Но это опять-таки если база не сильно большая.

dimuska139 ★★
()
Ответ на: комментарий от anonymous

Это шутка?

Нет. Падение в RO типично, впрочем, как и полный отказ с превращением в камень. Теория вероятности на практике.

anonymous
()
Ответ на: комментарий от Zhbert

Не в тему топика.

Они обычно в ридонли переходят, но читается как обычно все.

Серверные. А подавляющее большинство просто дохнет.

anc ★★★★★
()
Ответ на: комментарий от anc

Серверные. А подавляющее большинство просто дохнет.

Ну фиг знает. У меня был самсунг дешевые, за 3,5к, он в ридонли ушел.

Zhbert ★★★★★
()
Ответ на: комментарий от anc

Повезло. По моей практике большинство просто кирпич.

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

Zhbert ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.