https://opennet.ru/openforum/vsluhforumID1/97616.html Коллеги, приветствую!<br><br>Срочно нужна помощь (не бесплатно для того, кто поможет решить!). Суть проблемы:<br><br>есть одна группа томов LVM. На ней своп, корень и var. Недавно закончилось место на var. Обычная проблема, которая решается расширением диска.<br><br>На одной из машин произошло что-то непонятное. При создании раздела через fdisk (который должен был стать sda4) похерился sda3, который как раз физический том для vg1-varfs (/var). В итоге последний после ребута просто вывалился и не отображался в /dev/mapper/. Эту проблему я решил. Тут просто сбился по непонятным причинам uuid диска.<br><br>В в /dev/mapper/ появился varfs. Но он не хочет монтироваться, выдавая это: "wrong fs type, bad option, bad superblock on /dev/mapper/vg1-varfs".<br><br>fsck оказался бесполезен. Через DD сняли образ с проблемного раздела. Если кто может помочь достать оттуда данные, готов предоставить доступ к нему.<br> https://opennet.ru/openforum/vsluhforumID1/97616.html#11 Thu, 24 Jun 2021 00:11:15 GMT &gt;[оверквотинг удален]<br>&gt; дискам, сколько пропало.<br>&gt; Есть варианты настройки, когда потери меньше. Но эти меньше-больше отчасти неохватны, неопределённы. <br>&gt; Как правило для точной оценки потери нужна какая-то инфа со стороны. <br>&gt; В идеале такая инфа и есть бэкапы. У кого-то это могут <br>&gt; быть какие-то индексы и хэши. У кого-то точно объём потерь не <br>&gt; оценить.<br>&gt; Поэтому: данные ложатся условно непредсказуемо (отчасти), восстановить можно ооочень <br>&gt; много даже просто автоматами, но трудно абсолютно точно определить где потери. <br>&gt; Воссатновить можно очень много, но правильнее заранее делать копии и не тратить <br>&gt; время.<br><br>Спасибо, я понял. Надо искать варианты, LVM слишком долго будет восстанавливаться.<br> https://opennet.ru/openforum/vsluhforumID1/97616.html#10 Mon, 21 Jun 2021 17:49:57 GMT &gt; ну я же совсем не это спрашивал, я спрашивал как работает LVM <br>&gt; в подобных случаях, и можно ли восстановить часть данных после потери <br>&gt; PV <br><br>Можно восстановить. Алгоритм едйствий примерно такой:<br>- создать дамп остатков,<br>- запустить ПО той или иной степени продвинутости, автоматизирующее писк известных структур данных,<br>- из всех найденных вариантов трактовки скриптами остатков выбрать перспективные и скопировать нужные файлы.<br><br>Фокус в том, что структуры данных на диске - таблицы разделов, заголовки файловых систем, RAID, LVM - можно определять по известным последовательностям байтов и структуры нередко дублированы by design. Дальше это анализируют и пытаются склеить. Делают автоматически, иначе титаническая работа.<br><br>А в остальном кому как повезёт, смотря как структуры данных отлегли по дискам, сколько пропало.<br><br>Есть варианты настройки, когда потери меньше. Но эти меньше-больше отчасти неохватны, неопределённы. Как правило для точной оценки потери нужна какая-то инфа со стороны. В идеале такая и https://opennet.ru/openforum/vsluhforumID1/97616.html#9 Mon, 21 Jun 2021 14:55:55 GMT &gt;[оверквотинг удален]<br>&gt;&gt; Спорна способность LVM работать как RAID-1, для ценных вещей может и <br>&gt;&gt; не стоит.<br>&gt;&gt; В любом случае: LVM и RAID сделаны не для надёжности, а для <br>&gt;&gt; упрощения непрерывности. Надёжность (цена получения данных обратно) и непрерывность (возможность <br>&gt;&gt; не останавливать сервер до зарплаты для покупки замены диска) - разные <br>&gt;&gt; вещи.<br>&gt;&gt; Самое правильное - правильно сделанный бекап.<br>&gt; ну я же совсем не это спрашивал, я спрашивал как работает LVM <br>&gt; в подобных случаях, и можно ли восстановить часть данных после потери <br>&gt; PV <br><br>Обычно можно. Но я только учусь, поэтому послушаю умных людей )<br> https://opennet.ru/openforum/vsluhforumID1/97616.html#8 Mon, 14 Jun 2021 21:06:44 GMT &gt;[оверквотинг удален]<br>&gt; LVM специально придуман чтобы не знать и не думать как оно делит <br>&gt; данные между физ.томами.<br>&gt; Если нужно дублирование на ходу, то, вероятно, LVM поверх MD RAID 1. <br>&gt; Спорна способность LVM работать как RAID-1, для ценных вещей может и <br>&gt; не стоит.<br>&gt; В любом случае: LVM и RAID сделаны не для надёжности, а для <br>&gt; упрощения непрерывности. Надёжность (цена получения данных обратно) и непрерывность (возможность <br>&gt; не останавливать сервер до зарплаты для покупки замены диска) - разные <br>&gt; вещи.<br>&gt; Самое правильное - правильно сделанный бекап.<br><br>ну я же совсем не это спрашивал, я спрашивал как работает LVM в подобных случаях, и можно ли восстановить часть данных после потери PV<br> https://opennet.ru/openforum/vsluhforumID1/97616.html#7 Mon, 14 Jun 2021 17:14:46 GMT &gt; Собственно 1) возможно это? 2) как это правильно сделать? 3) Если не <br>&gt; с LVM, то какие варианты?<br><br>Что именно правильно сделать - чисто конкретно что именно?<br><br>Самое правильное - бекапы. Бекап агент сам приходит снаружи. С контролем, что бекапы работают, с проверяемым умением восстанавливаться. В идеале в две независымые точки, но ту уж у кого сколько денег.<br><br>LVM специально придуман чтобы не знать и не думать как оно делит данные между физ.томами.<br><br>Если нужно дублирование на ходу, то, вероятно, LVM поверх MD RAID 1. Спорна способность LVM работать как RAID-1, для ценных вещей может и не стоит.<br><br>В любом случае: LVM и RAID сделаны не для надёжности, а для упрощения непрерывности. Надёжность (цена получения данных обратно) и непрерывность (возможность не останавливать сервер до зарплаты для покупки замены диска) - разные вещи.<br><br>Самое правильное - правильно сделанный бекап.<br> https://opennet.ru/openforum/vsluhforumID1/97616.html#6 Mon, 14 Jun 2021 17:04:28 GMT R-Studio и - сам. )<br> https://opennet.ru/openforum/vsluhforumID1/97616.html#5 Thu, 10 Jun 2021 17:02:50 GMT &gt;[оверквотинг удален]<br>&gt;&gt; может помочь достать оттуда данные, готов предоставить доступ к нему.<br>&gt; Коллеги, спасибо большое всем, кто присоединился к теме и ответил. Проблему я <br>&gt; решил. Если кому интересно как, то отвечаю: <br>&gt; Через DD сделал дамп всего раздела, который не монтировался. После этого установил <br>&gt; testdisk, через него подключился к образу и увидел все файлы, которые <br>&gt; нас интересовали. Затем уже просто их скопировал на нормальный диск средствами <br>&gt; testdisk.<br>&gt; Все данные в полном порядке. Кроме того, tesdisk еще и кучу удаленных <br>&gt; файлов помог увидеть. Вообще, в этом не было необходимости, просто оказалось <br>&gt; приятным бонусом:) <br><br>Ребята у меня есть вопрос. На всякий случай хочу знать, до того как грянет гром.<br><br>У меня есть 3 PV, 1 VG, 1LV на всю емкость.<br><br>Если похерится 1 PV скажем так самый последний, который допустим еще не успел записаться данными, то я смогу получить доступ к файлам, которые на первых двух PV?<br><br>Или скажем если даже 3ий PV тоже с файлами, и я их тереяю, но п https://opennet.ru/openforum/vsluhforumID1/97616.html#4 Mon, 20 Jul 2020 04:15:41 GMT &gt;[оверквотинг удален]<br>&gt; закончилось место на var. Обычная проблема, которая решается расширением диска.<br>&gt; На одной из машин произошло что-то непонятное. При создании раздела через fdisk <br>&gt; (который должен был стать sda4) похерился sda3, который как раз физический <br>&gt; том для vg1-varfs (/var). В итоге последний после ребута просто вывалился <br>&gt; и не отображался в /dev/mapper/. Эту проблему я решил. Тут просто <br>&gt; сбился по непонятным причинам uuid диска.<br>&gt; В в /dev/mapper/ появился varfs. Но он не хочет монтироваться, выдавая это: <br>&gt; "wrong fs type, bad option, bad superblock on /dev/mapper/vg1-varfs".<br>&gt; fsck оказался бесполезен. Через DD сняли образ с проблемного раздела. Если кто <br>&gt; может помочь достать оттуда данные, готов предоставить доступ к нему.<br><br>Коллеги, спасибо большое всем, кто присоединился к теме и ответил. Проблему я решил. Если кому интересно как, то отвечаю:<br><br>Через DD сделал дамп всего раздела, который не монтировался. После этого установил testdisk, через него подключился к образу https://opennet.ru/openforum/vsluhforumID1/97616.html#3 Mon, 20 Jul 2020 04:07:55 GMT &gt; есть одна группа томов LVM. На ней своп, корень и var. Недавно <br>&gt; закончилось место на var. Обычная проблема, которая решается расширением диска.<br><br>Обычная проблема "закончилось место" решается расширением конкретного раздела, lvresize.<br>Не наезд, просто чтобы понять что там было. У вас закончилось место на Volume Group, но было неразмеченное место на sda, и вы решили его заюзать в качестве дополнительного Phisical Volume?<br><br>&gt; На одной из машин произошло что-то непонятное. <br><br>А машин что, несколько? Одинаковых? Если так, то посмотрите на соседней, где на самом деле начинаются и заканчиваются разделы.<br><br>&gt; При создании раздела через fdisk <br>&gt; (который должен был стать sda4) похерился sda3, который как раз физический <br>&gt; том для vg1-varfs (/var).<br><br>Или ищите начало и конец своего sda3 с помощью tesdisk-а.<br>https://www.cgsecurity.org/wiki/TestDisk<br><br>&gt; В итоге последний после ребута просто вывалился <br>&gt; и не отображался в /dev/mapper/. Эту проблему я решил. Тут просто <br>&gt; сбился по непонятным причинам uuid д