- Проблема с разделом LVM и суперблоками, ACCA, 15:55 , 17-Июл-20 (1)
> и не отображался в /dev/mapper/. Эту проблему я решил. Тут просто > сбился по непонятным причинам uuid диска.Есть мнение, что похерилась-таки partition table. Теперь /dev/sda3 показывает в какое-то другое место. Потом ты обманул devmapper, но не mount. > fsck оказался бесполезен. Через DD сняли образ с проблемного раздела. Если кто > может помочь достать оттуда данные, готов предоставить доступ к нему. Данных там нет, они где-то в другом месте. Нужен dd всего физического диска. Если они ещё где-то остались.
- Проблема с разделом LVM и суперблоками, Павел Отредиез, 11:14 , 18-Июл-20 (2)
>[оверквотинг удален] > закончилось место на var. Обычная проблема, которая решается расширением диска. > На одной из машин произошло что-то непонятное. При создании раздела через fdisk > (который должен был стать sda4) похерился sda3, который как раз физический > том для vg1-varfs (/var). В итоге последний после ребута просто вывалился > и не отображался в /dev/mapper/. Эту проблему я решил. Тут просто > сбился по непонятным причинам uuid диска. > В в /dev/mapper/ появился varfs. Но он не хочет монтироваться, выдавая это: > "wrong fs type, bad option, bad superblock on /dev/mapper/vg1-varfs". > fsck оказался бесполезен. Через DD сняли образ с проблемного раздела. Если кто > может помочь достать оттуда данные, готов предоставить доступ к нему.Хотя бы листинг старой разметки есть? Если пересоздать разделы как было, есть шанс. Uuid раздела изменился потому что он изменился.
- Проблема с разделом LVM и суперблоками, Licha Morada, 07:07 , 20-Июл-20 (3)
> есть одна группа томов LVM. На ней своп, корень и var. Недавно > закончилось место на var. Обычная проблема, которая решается расширением диска.Обычная проблема "закончилось место" решается расширением конкретного раздела, lvresize. Не наезд, просто чтобы понять что там было. У вас закончилось место на Volume Group, но было неразмеченное место на sda, и вы решили его заюзать в качестве дополнительного Phisical Volume? > На одной из машин произошло что-то непонятное. А машин что, несколько? Одинаковых? Если так, то посмотрите на соседней, где на самом деле начинаются и заканчиваются разделы. > При создании раздела через fdisk > (который должен был стать sda4) похерился sda3, который как раз физический > том для vg1-varfs (/var). Или ищите начало и конец своего sda3 с помощью tesdisk-а. https://www.cgsecurity.org/wiki/TestDisk > В итоге последний после ребута просто вывалился > и не отображался в /dev/mapper/. Эту проблему я решил. Тут просто > сбился по непонятным причинам uuid диска. Уже выше написали. Имеет смысл предположить, что не "просто сбился" и не решил, а теперь там не блочное устройство со слегка побитой файловой системой, а полное недоразумение. И откатиться обратно, до состояния "похерился sda3", чтобы диагностировать и испарвлять правильно. - Проблема с разделом LVM и суперблоками, Murano, 07:15 , 20-Июл-20 (4)
>[оверквотинг удален] > закончилось место на var. Обычная проблема, которая решается расширением диска. > На одной из машин произошло что-то непонятное. При создании раздела через fdisk > (который должен был стать sda4) похерился sda3, который как раз физический > том для vg1-varfs (/var). В итоге последний после ребута просто вывалился > и не отображался в /dev/mapper/. Эту проблему я решил. Тут просто > сбился по непонятным причинам uuid диска. > В в /dev/mapper/ появился varfs. Но он не хочет монтироваться, выдавая это: > "wrong fs type, bad option, bad superblock on /dev/mapper/vg1-varfs". > fsck оказался бесполезен. Через DD сняли образ с проблемного раздела. Если кто > может помочь достать оттуда данные, готов предоставить доступ к нему.Коллеги, спасибо большое всем, кто присоединился к теме и ответил. Проблему я решил. Если кому интересно как, то отвечаю: Через DD сделал дамп всего раздела, который не монтировался. После этого установил testdisk, через него подключился к образу и увидел все файлы, которые нас интересовали. Затем уже просто их скопировал на нормальный диск средствами testdisk. Все данные в полном порядке. Кроме того, tesdisk еще и кучу удаленных файлов помог увидеть. Вообще, в этом не было необходимости, просто оказалось приятным бонусом:)
- Проблема с разделом LVM и суперблоками, penetrator, 20:02 , 10-Июн-21 (5)
>[оверквотинг удален] >> может помочь достать оттуда данные, готов предоставить доступ к нему. > Коллеги, спасибо большое всем, кто присоединился к теме и ответил. Проблему я > решил. Если кому интересно как, то отвечаю: > Через DD сделал дамп всего раздела, который не монтировался. После этого установил > testdisk, через него подключился к образу и увидел все файлы, которые > нас интересовали. Затем уже просто их скопировал на нормальный диск средствами > testdisk. > Все данные в полном порядке. Кроме того, tesdisk еще и кучу удаленных > файлов помог увидеть. Вообще, в этом не было необходимости, просто оказалось > приятным бонусом:) Ребята у меня есть вопрос. На всякий случай хочу знать, до того как грянет гром. У меня есть 3 PV, 1 VG, 1LV на всю емкость. Если похерится 1 PV скажем так самый последний, который допустим еще не успел записаться данными, то я смогу получить доступ к файлам, которые на первых двух PV? Или скажем если даже 3ий PV тоже с файлами, и я их тереяю, но получаю доступ к первым двум. Собственно 1) возможно это? 2) как это правильно сделать? 3) Если не с LVM, то какие варианты?
- Проблема с разделом LVM и суперблоками, Анто Нимно, 20:14 , 14-Июн-21 (7)
> Собственно 1) возможно это? 2) как это правильно сделать? 3) Если не > с LVM, то какие варианты?Что именно правильно сделать - чисто конкретно что именно? Самое правильное - бекапы. Бекап агент сам приходит снаружи. С контролем, что бекапы работают, с проверяемым умением восстанавливаться. В идеале в две независымые точки, но ту уж у кого сколько денег. LVM специально придуман чтобы не знать и не думать как оно делит данные между физ.томами. Если нужно дублирование на ходу, то, вероятно, LVM поверх MD RAID 1. Спорна способность LVM работать как RAID-1, для ценных вещей может и не стоит. В любом случае: LVM и RAID сделаны не для надёжности, а для упрощения непрерывности. Надёжность (цена получения данных обратно) и непрерывность (возможность не останавливать сервер до зарплаты для покупки замены диска) - разные вещи. Самое правильное - правильно сделанный бекап.
- Проблема с разделом LVM и суперблоками, penetrator, 00:06 , 15-Июн-21 (8)
>[оверквотинг удален] > LVM специально придуман чтобы не знать и не думать как оно делит > данные между физ.томами. > Если нужно дублирование на ходу, то, вероятно, LVM поверх MD RAID 1. > Спорна способность LVM работать как RAID-1, для ценных вещей может и > не стоит. > В любом случае: LVM и RAID сделаны не для надёжности, а для > упрощения непрерывности. Надёжность (цена получения данных обратно) и непрерывность (возможность > не останавливать сервер до зарплаты для покупки замены диска) - разные > вещи. > Самое правильное - правильно сделанный бекап.ну я же совсем не это спрашивал, я спрашивал как работает LVM в подобных случаях, и можно ли восстановить часть данных после потери PV
- Проблема с разделом LVM и суперблоками, Ilugar, 17:55 , 21-Июн-21 (9)
>[оверквотинг удален] >> Спорна способность LVM работать как RAID-1, для ценных вещей может и >> не стоит. >> В любом случае: LVM и RAID сделаны не для надёжности, а для >> упрощения непрерывности. Надёжность (цена получения данных обратно) и непрерывность (возможность >> не останавливать сервер до зарплаты для покупки замены диска) - разные >> вещи. >> Самое правильное - правильно сделанный бекап. > ну я же совсем не это спрашивал, я спрашивал как работает LVM > в подобных случаях, и можно ли восстановить часть данных после потери > PV Обычно можно. Но я только учусь, поэтому послушаю умных людей )
- Проблема с разделом LVM и суперблоками, Анто Нимно, 20:49 , 21-Июн-21 (10)
> ну я же совсем не это спрашивал, я спрашивал как работает LVM > в подобных случаях, и можно ли восстановить часть данных после потери > PV Можно восстановить. Алгоритм едйствий примерно такой: - создать дамп остатков, - запустить ПО той или иной степени продвинутости, автоматизирующее писк известных структур данных, - из всех найденных вариантов трактовки скриптами остатков выбрать перспективные и скопировать нужные файлы. Фокус в том, что структуры данных на диске - таблицы разделов, заголовки файловых систем, RAID, LVM - можно определять по известным последовательностям байтов и структуры нередко дублированы by design. Дальше это анализируют и пытаются склеить. Делают автоматически, иначе титаническая работа. А в остальном кому как повезёт, смотря как структуры данных отлегли по дискам, сколько пропало. Есть варианты настройки, когда потери меньше. Но эти меньше-больше отчасти неохватны, неопределённы. Как правило для точной оценки потери нужна какая-то инфа со стороны. В идеале такая инфа и есть бэкапы. У кого-то это могут быть какие-то индексы и хэши. У кого-то точно объём потерь не оценить. Поэтому: данные ложатся условно непредсказуемо (отчасти), восстановить можно ооочень много даже просто автоматами, но трудно абсолютно точно определить где потери.
Воссатновить можно очень много, но правильнее заранее делать копии и не тратить время.
- Проблема с разделом LVM и суперблоками, penetrator, 03:11 , 24-Июн-21 (11)
>[оверквотинг удален] > дискам, сколько пропало. > Есть варианты настройки, когда потери меньше. Но эти меньше-больше отчасти неохватны, неопределённы. > Как правило для точной оценки потери нужна какая-то инфа со стороны. > В идеале такая инфа и есть бэкапы. У кого-то это могут > быть какие-то индексы и хэши. У кого-то точно объём потерь не > оценить. > Поэтому: данные ложатся условно непредсказуемо (отчасти), восстановить можно ооочень > много даже просто автоматами, но трудно абсолютно точно определить где потери. > Воссатновить можно очень много, но правильнее заранее делать копии и не тратить > время.Спасибо, я понял. Надо искать варианты, LVM слишком долго будет восстанавливаться.
- Проблема с разделом LVM и суперблоками, Анто Нимно, 20:04 , 14-Июн-21 (6)
|