LINUX.ORG.RU
ФорумAdmin

Стабильная файловая система для внешнего SSD

 , , ,


0

3

Всем привет! Есть внешний SSD диск на 4TB, предназначенный для бекапов. Для меня главное сохранность данных. Диск будет постоянно подключен через USB type-C к стационарному компьютеру(возможно отключение света), на котором две ОС. Fedora и Windows 10(использование крайне редко). Я прочитал много статей по выбору файловой системы и остановился на ext4. Но все равно хотелось бы мнение пользователей на 2024 год, возможно я не прав.

Также рассматривал btrfs, но получается главный ее недостаток в том, что ext4 стабильнее, а с btrfs есть случаи жалоб на необходимость восстановления фс, например при отключении света. Снимки мне не нужны. Сжатие тоже. На диске будут архивы, у которых вряд ли фс найдет одинаковые участки, для сохранения места на диске.

Минус ext4, это журналирование, которое съело 200 гигабайт (5%). Может и стоит отключить, но мне кажется журналирование как раз спасет от проблем при отключении света.

Изначально диск был разбит под exfat(3.6гигабайт). Мне не надо, чтобы диск был доступен из под Windows, наоборот(может и паранойя), но я боюсь, что какой-нибудь случайно подхваченный троян испортит файлы на внешнем диске. Винда же автоматически монтирует все. Также главный минус exfat, в том, что эта фс очень прихотливая для названий файлов. Не различает регистр имён файлов.

Ntfs я не рассматриваю.

Спасибо.

Перемещено hobbit из general

остановился на ext4

Правильный выбор, с точки зрения надёжности - так точно.

журналирование, которое съело 200 гигабайт (5%)

Это не журналирование, а резерв для рута. На таких объёмах оставлять больше 0.01% - смысла нет. tune2fs -m 0 <device> спасёт отца русской демократии.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 2)

Вы не с того конца заходите, с технического, а надо с организационного.

Для сохранности бэкапов организуйте схему «3,2,1»: три копии, две из них на на разных носителях (например одна копия на внешнем SSD, вторая в каталоге на вашем NAS) + ещё одна копия в «холодном облаке» в интернете.

Сам по себе SSD способен сломаться так что данные с него снять будет крайне сложно, вплоть до невозможности, в отличии от механики, где это обычно вопрос денег. Выбор ФС тут на последнем месте должен стоять, это вообще практически неважно.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

У тебя 3-2-1 звучит как будто подразумевается три резервных копии. Хотя это хорошо, и я сам так делаю, это уже 4-3-1. 3-2-1 в общепринятой формулировке включает одну рабочую копию и две резервных.

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

Ну я в такой формулировке встречал. Рабочие данные по определению не резервная копия. Имеются ввиду три резервных копии рабочих данных ессно. У меня так и сделано, бэкаплюсь одновременно на внешний SSD и в расшаренный каталог NAS. А NAS уже автомагически синхронизирует этот каталог с «холодным хранилищем» Яндекса по S3.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

Рабочие данные по определению не резервная копия.

А 3-2-1 в стандартном определении не говорит о любых, а не только резервных. Это я не из вредности придираюсь, но для большей ясности обсуждения. Проверить можно в гугле, схема описана многими известными компаниями.

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

Ну я в такой формулировке встречал.

Как по мне - так гораздо важнее и полезнее иметь несколько периодических копий (например, полные - каждую неделю и инкрементальные - каждый день или час), чем несколько идентичных на разных носителях / в разных локациях. Мои 2 копейки.

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

Если понадобится — придётся заплатить, да. Но для того и существуют ещё две копии, «облачная» это на крайний случай, типа полного выгорания или конфискации всего электонного имущества «на исследование» при обыске например. Ну и объёмы у нас не те для «обычного диска».

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

Так можно комбинировать же. А можно разделять — накопительные для данных которые десятки лет могут храниться и быть однажды востребованы, инкрементальные периодические для «disaster recovery». У меня инкрементальные периодические копии делаются для самих серверных ОС и для баз данных, просто с них в случае чего восстановиться проще и быстрее чем переустанавливать.

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

Зачем выбирать и делить на полные и инкрементальные, когда есть restic или borg?

На самом деле это уже детали: как именно оно будет организовано - это дело десятое. Важна сама концепция. А прелесть инкрементальных бекапов в их простоте и «обкатанности» технологии - банальный tar это умеет делать много дцать лет как, и поддерживается каждым утюгом.

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

У меня итак несколько SSD дисков. А что вы подразумеваете под механикой? HDD? Тоже есть, с них сейчас на ssd и перехожу. А вот облачному я почему-то не доверяю, либо не до конца принцип облака понимаю. Ведь если вы говорите, что ssd может умереть и все данные потеряются, почему нет вероятности, что сервер, где хранятся ваши файлы сгорит, его затопят или просто тоже умрет? Банально аккаунт могут заблокировать, взломать. Почему все так доверяют облачному хранению?

Кстати сейчас копировал с hdd toshiba, там по умолчанию был exfat, но потом оказалось, что fuseblk, стал копировать на exfat Samsung ssd, и часть файлов потерялось. Поэтому и решил на ext4 сменить.

user2021
() автор топика
Последнее исправление: user2021 (всего исправлений: 1)
Ответ на: комментарий от user2021

Суть в том что доверять можно только совокупности методов, по отдельности каждый из них ненадёжен, а в совокупности потерять одновременно все три копии в разных местах крайне маловероятное событие. А облако хорошо хотя бы тем что оно физически «вовне». И даже если здание с двумя другими копиями будет уничтожено целиком — будет шанс восстановиться с облака. Ну а если облако взломают, потеряют там данные и т.п. — ну есть другие две копии, а облако можно сменить на более другое перезаключив договор.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

потерять одновременно

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

И, разве, с современных НЖМД с черепиченой записью что-то достать можно?

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

С SSD неприятно то что данные с них не всегда можно восстановить, он может так помереть что с него вообще ничего снять не удастся. С механики например мне снимали данные даже с запиленных отломавшейся бошкою блинов, путём перестановки этих блинов. Дорого, и с частичной потерей, но большую часть удалось достать.

Но опять таки, это всё не актуально если есть ещё две копии. Тогда можно тупо ничего не восстанавливать, а просто заменить носитель.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от mky

Дак это надо переодически проверять, что копии читаемые, с правильной контрольной суммой…

Современные средства резервного копирования делают это удобным. С синхронизацией с облаком то же самое, правда, без скачивания придётся доверять хэшам с сервера.

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

Я по старинке копировал через mc, удивился потом, что размер директорий не совпадает, начал сверять, оказывается было два файла с разным регистром имён. Почему-то fuseblk позволяет разные регистры, а exfat от Samsung нет.

Задумался на счёт облака, какое самое удобное? С учётом санкций в России наверное Яндекс? Погуглил, есть статьи, которые пугают, что у Яндекса проблемы со свободным местом. Ещё какие-нибудь есть с оплатой из России?

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

оказывается было два файла с разным регистром имён

Вас ждёт ещё много сюрпризов. Если бы я делал ставку - следующим будет hardlinks. Невозможно сделать копию fs с бОльшим функционалом на условно «ущербную». И «mc» - это не тот tool который нужно использовать для копирования, как резервного, так и «exact copy».

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

Поэтому тему и создал. Хотелось бы фс без сюрпризов ! Т.к. первоначально копировал из системы с ext4 файлы на внешний диск с fuseblk(как я до этого думал exfat). Потом понял, что лучше кучу мелких файлов объединять через tar. Однако опять попал tar на mac os совершенно не такой, как tar на Линуксе, он ущербный и обрезает длинные имена файлов и ещё кучу приколов. Приходилось использовать zip для объединения файлов. Сейчас ушел с мак ос, чему очень доволен, и привожу все данные в порядок.

user2021
() автор топика
Последнее исправление: user2021 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Да есть сюрпризы и с архиваторами, пример с tar на мак ос, я написал выше. А все потому, что почему-то в портах мака не тот tar, который есть на Линуксе.

Второй сюрприз, с архиватором rar. Вроде бы две почти одинаковых команды заархивируют содержимое директории dir по разному. И можно потерять очень много важных файлов.

rar a ar.rar dir
rar a ar.rar dir/

Но это все оффтоп, я почему-то думал, что линуксоиды будут отговаривать меня от устаревшей ext4, и уговаривать на btrfs, которая бережет ssd диск, или zfs и т.д..

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

btrfs, которая бережет ssd диск

Вот что-что, а ssd-диски btrfs не бережёт, увы. B-деревья вообще не способствуют экономии пропускной способности, и показатели по write amplification у btrfs одни из худших (были когда-то).

Тут, конечно, нужно заметить, что на практике, если SSD не абсолютное китайское дерьмище, ты этого не заметишь. Он либо морально устареет, либо сдохнет по процу/электронике гораздо раньше, чем износится NAND. Но объективный факт именно таков.

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

Без понятия что там на маках, возможно там просто по умолчанию tar создаёт архивы другого стандарта (posix вместо gnu), или ты просто какой-то ключ пропустил. Если не нравится tar, можно ещё dar попробовать. Использовать на внешних накопителях журналируемую ФС смысла нет – либо exfat (если нужна совместимость с виндой), либо ext2, либо f2fs. Btrfs точно использовать не нужно, ибо это будет лютейший оверхед без каких-либо видимых преимуществ.

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

Это не копия, это архив.

Заархивированная копия. Более того, если бэкапы делаются на HDD и содержат много мелких файлов, то сжатый архив – это единственный способ избежать лютых тормозов.

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

то сжатый архив – это единственный способ избежать лютых тормозов

Я ни в одном глазу не оспариваю полезность оных, и для backups - самое то. Но говорить про «тормоза» в этом контексте (архивы vs «развёрнутые» копии) - не очень корректно: достаньте мне один мелкий файл из середины tar архива, ага.

bugfixer ★★★★★
()

Минус ext4, это журналирование, которое съело 200 гигабайт (5%). Может и стоит отключить, но мне кажется журналирование как раз спасет от проблем при отключении света.

Ты, часом, не про это?


-m reserved-blocks-percentage
... The default percentage is 5%.

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

DAR при создании архива производит индексацию файлов, поэтому его открытие занимает очень мало времени. А вообще если тебе нужен постоянный доступ к файлам, то это уже никакой не бэкап. Тут уже скорее NAS нужен, которого правда самого куда-то нужно будет бэкапить.

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

Использовать на внешних накопителях журналируемую ФС смысла нет – либо exfat …, либо ext2, либо f2fs.

Да ну конечно, так прям и нету смысла! Ты сейчас расскажешь!

anonymous
()

Больше клинических идиотов местных читай, которым интернет в дурку провели. Нормальные давно свалили. Не разваливается btrfs при выключении света. В ней данные последовательно пишутся в новое мест. Те если вырубится свет, то ты в 1/10 случаев получишь ошибку проверки чексум, те битый файл. Вместо raid-1 в btrfs, сиди бекапь, будь макакой. Они даже lvm не упомянули со снапшотами… У btrfs скорость +/- такая же как у ext4. Выбор сводится лишь к тому нужны ли тебе машина времени со снапшотами и встроенное сжатие. Если на оба вопроса ответ нет, то используй ext4.

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

Выбор сводится лишь к тому нужны ли тебе машина времени со снапшотами и встроенное сжатие.

Мнения разнятся. Готов предположить что «важные» данные с corrupted fs вам доставать не приходилось. Ваша экзотика - ваши риски. Вперёд.

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

Задумался на счёт облака, какое самое удобное?

Зачем выбирать одно? Сделай многотомный архив, раскидай по всем облакам Очень важные данные храни на всех. Должно ж хватить бесплатного тарифа для них? Просто важные там где удобно, выгодно.

Restic умеет через rclone бэкапить сразу в облака. Из местных: яндекс, майл.ру, и которые могут в webdav. Яндекс, правда, режет скорость rclone’у, а майл.ру не любит многопоточность. На webdav есть диск у Сбера, у меня не заработало.

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

Очень важные данные храни на всех. Должно ж хватить бесплатного тарифа для них? Просто важные там где удобно, выгодно.

О как. Возможно это подразумевалось - но не забудьте упомянуть о криптовании, и надёжном хранении ключей (что является отдельной темой). Я бы 20 раз подумал прежде чем свои «важные» данные «дяде» отдавать. Рисков там я вижу даже больше чем в потере данных как таковых.

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

А если просто использовать пароли для шифрования или архивы с паролями. Это не надёжно? Пароль даже самый сложный можно запомнить, а вот ключ надо где-то хранить. Я только rar знаю, вроде бы как с шифрацией и возможностью установить пароль, но у него закрытый код, доверять наверное не стоит. Что ещё можно из этого попробовать?

user2021
() автор топика