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

Ого, ну и бред)

Качественнее набрасывай, в деталях.

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

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

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

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

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

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

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

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

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

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

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

с «холодным хранилищем» Яндекса по S3

Разве это не в разы дороже обычного их диска, особенно если понадобится восстановление?

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

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

не говорит

не говорит

Упс.

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

у нас

А, организация? Ну, тогда вам и не положено использовать обычный диск под задачи инфраструктуры :)

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

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

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

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

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

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

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

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

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

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

А если хранить десять копий в десяти разных местах, то потеря данных будет ещё менее вероятной.

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

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

ХЗ если честно.

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

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

стал копировать на exfat Samsung ssd, и часть файлов потерялось.

Дайте угадаю: symlinks / hardlinks? Names case-sensitivity? Extended attributes? Sparse files? И что значит «копировать»?

ntfs

Читай что на аватарке написано: я низкокачественная наживка)

ntfs

Это тот который в Линукс даже проверить нечем? Отличный выбор, да.

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

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

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

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

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

Невозможно сделать копию fs с бОльшим функционалом на условно «ущербную».

А что, архиваторы уже не в моде?

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

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

rar a ar.rar dir

rar a ar.rar dir/

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

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

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

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

А что, архиваторы уже не в моде?

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

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

ZFS.

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

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

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

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

Используй floppy disk

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

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

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

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

exFAT

Формат не предполагает random access без полного чтения. Что я упускаю?

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

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

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

dar — это не tar

А в принципе можно создать файл со squashfs/erofs

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

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

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

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

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

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

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

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

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