Pull to refresh

Comments 87

Понятно, что смысл статьи не в этом, но последний чувак удивил. Если у тебя 80,000 дорогих тебе фото находятся лишь на одном девайсе, который и без хакерской атаки может сам по себе кирдыкнуться, то что-то не так с твоей бекап стратегией. Особенно, во времена дешевых облаков.
UFO just landed and posted this here

Очевидно, что именно у него баланс никакой

У меня на одном девайсе находятся 200 тысяч фотографий (фулсайзы в RAW, несколько терабайт). Это RAID-массив в NAS (слава богу, не WD). Куда мне положить бэкап бэкапов и не разориться?

Не иронизирую, серьёзный вопрос: ширина канала не позволяет залить на какой-нибудь Amazon Glacier; положить всё на отдельный жёсткий диск — не спасёт от пожара; ну и так далее.
Куда мне положить бэкап бэкапов и не разориться?


я покупаю место у Google Drive но только 100Гб и бэкаплю самое важное. Дисковое место дешевое как для компаний, но не как для отдельного юзера.

Попробуйте opendrive.com. У них персональный тариф 99$ в год, и по их условиям он рассчитан на объём хранения около 10 TB (после чего они начинают зарезать скорость). Он конечно немного тормозной и родной клиент у них так себе, но для долговременного хранения нормально, и rclone решает проблему с клиентом. Тот же rclone позволяет дополнительно при загрузке файлов шифровать их собственным ключом, который не улетает на сервер.

Mass storage of media libraries and NAS/SAN devices not permitted on this plan.

Не уверен что они как-то это определяют, если честно, вдобавок если прижать ещё шифрованием. Но дело ваше.

Я бы на Вашем месте постарался найти место, куда можно отнести положить жесткий диск (возможно, зашифрованный): к друзьям, на работу в офис, ячейку камеры хранения.

Можно бэкапить на разные HDD, и хранить их в разных местах, с ротацией.

Ну и облачное хранилище я бы не отметал по причине ширины канала. У меня 0.5 mbit/s (да, пол-мегабита), свои 300 GB пришлось закачивать больше недели, зато теперь есть инкрементально обновляемый бэкап (через restic). Цена вопроса – $5/месяц.

LTO-4 стоит относительно недорого

А вы с ним вживую работали? Я почему спрашиваю — судя по описаниям, полноценная работа начинается только с LTO-5 (только там появляется поддержка нормальной эмуляции файловой системы), а работать с LTO-4 будет так же удобно, как раньше было с компакт-дисками.
В целом, я давно уже задумался о покупке соотв. девайса, но пока толком информации не нашел. Особенно волнует, как потом этот девайс с SAS на обычную SATA-материнку подключать.

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

Ну потому что так, архивами — неудобно. Я еще помню времена Nero и CD-RW. Да, так тоже жить можно, но…
Как я понял, LTO-5 обещает чуть-ли не банальную работу с лентой в проводнике, как с обычным диском

Лучше этого не делать, запись 100000+ мелких файлов очень качественно убивает ленту за один прогон, да и стримеру это не нравится. Банально берём и кидаем в LTFS большими архивами, если не используем всякие бакулы и прочее.
Пользуюсь LTO-5.
Из под Linux/FreeBSD можно писать обычным tar прямо на ленту и перематывать её командой mt.
tar, кстати, поддерживает многотомность (в FreeBSD — по умолчанию, не поддерживает, но там есть gtar, который умеет), за счёт чего можно сразу выгрузить на ленты хоть целый raid-массив.
Из минусов такого решения, нужно помнить, что записано на картридже, чтобы не перетереть случайно данные.

Пробовал и LTFS, драйвера для неё есть как для Linux, так и для Windows. Кучу мелких файлов всё-таки писать не стоит, постоянный старт/стоп для стримера не особенно полезен, да и просто очень долго получается. Кроме того, при чтении с LTFS желательно читать файлы в том порядке как они были записаны (можно смотреть по ID в LTFS Cartridge Brwser), иначе больше времени уйдёт на перемотку (до 90 секунд, если мотать от начала до конца ленты), чем на собственно чтение.

Поэтому, на мой взгляд, всё-таки предпочтительнее писать большими файлами, даже используя LTFS.
Ещё при записи мелких файлов, жёсткий диск может банально не поспевать за лентой, чтобы немного сгладить этот эффект использую mbuffer.

К SATA-контроллеру материнской платы стример подключить не получится, к SAS RAID контроллерам — может не заработать (зависит от наличия поддержки режима JBOD и размера блока, поддерживаемого RAID-контроллером), так что лучше сразу смотреть на SAS HBA вроде LSI 9200 или LSI 9300 и их аналогов.

Кроме того, желательно обеспечить стримеру нормальное охлаждение, во время работы он ощутимо греется, что тоже не полезно для него.

Ещё у лент есть аппаратное сжатие, позволяющее уместить немного больше, чем реальный объём ленты (для LTO-5 — 1.5 ТБ), реальная степень сжатия зависит от типа записываемых данных.

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

Если же нужен быстрый доступ к мелким файлам — только жёсткий диск на полке (что, впрочем, не мешает хранить копию этого диска на ленте).

У меня, в общем-то, конечная цель именно забэкапить все мои ~20 тб данных с винтов. Надежность современных емких винтов как-то резко падать начала, делать рейд на такой объем — это под 100 тыс выйдет, дорого. А ленты относительно дешевые, основные затраты только на стример получаются. Вот я и думаю, стоит ли заморачиваться. В основном у меня достаточно большие файлы, в крайнем случае мелкие можно по архивам распихать, так что проблемы с производительностью чтения/записи меня не очень волнуют, в принципе.

UFO just landed and posted this here
Стоит или не стоит, это всё-таки индивидуально, техника немного специфическая, к этому нужно быть готовым.

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

С проблемами, когда стример не видит записанное другим стримером сталкиваться не доводилось. Умершие кассеты попадались, правда обнаруживалось при проверке свежекупленных б/у.

Также желательно обзавестись чистящей кассетой. Просто так её использовать не стоит (она рассчитана на 15 использований, RFID внутри картриджа не даст обмануть это ограничение), только если загорелся соответствующий индикатор на стримере, или если есть проблемы с чтением записью.
Кстати, чистящие кассеты универсальны и с некоторыми оговорками подходят для любого LTO.

При выборе стримера советую запрашивать у продавца Support Ticket с информацией о состоянии стримера (если он согласится его предоставить, конечно), для его просмотра может понадобиться Library & Tape Tools, доступный бесплатно (возможно, потребуется регистрация), для работы с LTFS есть утилиты LTFS Cartridge Browser (просмотр списка файлов на лентах) и это относится к HP. У Tandberg и Quantum, если не путаю, те же утилиты (вроде даже взаимозаменяемые), с IBM дела не имел, возможно, всё то же самое, не в курсе.

Ленты можно найти на вторичном рынке. Если поискать, встречаются даже вполне живые за вполне разумные деньги (купил в своё время большую партию лент с 87% остаточного ресурса, согласно L&TT).

У LTO достаточно продвинутая система самодиагностики, в том числе сразу после записи выполняется проверка записанных данных, если в блоке есть ошибки, он пишется повторно. Из-за этого и из-за аппаратного сжатия ёмкость ленты может ощутимо плавать.
с 87% остаточного ресурса, согласно L&TT


а расскажите, пожалуйста, чуть подробнее. Про 8kb RFID видел инфу в доках. Но как её читать, что там лежит и как узнать остаточный ресурс ленты — не знаю.
RFID считывается встроенным в стример считывателем. Сама метка находится в передней части картриджа, с противоположной стороны от переключателя защиты от записи.

Если используется LTFS, посмотреть состояние картриджа можно прямо в проводнике Windows, в свойствах «диска» есть соответствующая вкладка.

Также можно посмотреть в Library & Tape Tools, можно создать Support Ticket, в нём будет подробная информация о стримере и последних 5 картриджах.

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

Возможно, есть и другие способы, но они мне неизвестны. Когда в следующий раз буду записывать данные, если не забуду попробую поковыряться в L&TT, может быть, найду ещё что-нибудь интересное.

Точной информации, что и как лежит на RFID у меня нет, только предположения исходя из информации, которую стример может получить о картридже.
Как минимум, судя по L&TT, о картридже известно:
Штрихкод на наклейке, серийный номер, информация о разделах и что-то вроде смарта на HDD, количество ошибок разных видов, максимальная зафиксированная температура картриджа (хотя кто её измеряет — не понял), объём записанной/прочитанной информации, количество перемоток, общий пробег ленты (на всякий случай, длина ленты у LTO-5 860м, картридж записывается полностью за 80 проходов).
И если информация о последней сессии записи, вполне может хранится в стримере, то такие вещи как суммарный пробег, серийные номера, данные о разделах и т. д., явно хранятся в картридже.
так что лучше сразу смотреть на SAS HBA вроде LSI 9200 или LSI 9300 и их аналогов.


А почему не на FibreChannel? 4GB Контроллеры на авито от 500р
В сообщении на которое я отвечал, человек спрашивал
Особенно волнует, как потом этот девайс с SAS на обычную SATA-материнку подключать.

Поэтому написал про SAS HBA.
А так да, можно и по FC подключить, если у стримера соответствующий интерфейс

Купить LTO драйв, предыдущих поколений и картриджи к нему. Холодные бэкапы, на картриджах, хранить в другом, по отношению к NAS, месте (банковская ячейка, квартира подруги etc).

У меня аналогичная ситуация - RAID1 для всего дорого душе и сердцу. Для бэкапа периодически просто делаю rsync на диск, 90% времени лежащий в ящике стола. Причем сам файловый сервер стоит у родителей, а ящик стола с диском находится у меня в квартире. Диск на 4 ТБ, пока хватает, но в случае нехватки, думаю, совсем неразорительно купить просто три диска на нужный объем и собрать новую конфигурацию RAID1+оффлайн диск.

Дропбокс за вполне доступные деньги дает 5ТБ. А за еще чуть большую сумму может дать условный безлимит (условный, потому что повышение квоты надо запрашивать).

Хотелось бы пояснений, что не так с дропбоксом. Я использую, удобно. Было даже, что случайно удалил файл, так смог его восстановить из бекапа на дропбоксе (там можно в течение определенного периода восстановить измененный или удаленный файл).

UFO just landed and posted this here
У меня LTE, и после ~100 гигабайт исходящего трафика в месяц начинаются проблемы.
На мои 10 ТБ мне в текущей ситуации понадобится ~8 лет. Поэтому действительно нужно иметь пару внешних дисков у знакомых, не забывать их регулярно забирать и обновлять бэкапы.

Родственников нет, которым можно отдать на хранение шифрованный жесткий диск?

Тогда ячейка в банке.

Насколько я понял - облако не рассматривается, а то бы предложил Microsoft 365 для семьи. 6 аккаунтов по по терабайту в OneDrive, менеджмент данных через rclone.

Используйте backblaze b2. В этом облаке цены что-то типа 1 цент за гигабайт. А недавно ещё появился S3 интерфейс. Так что возможно ваш NAS может сам автоматом делать бекап в это облако.

Купи ещё диск, храни в несгораемом сейфе. Диск обновляй после истечения гарантии

В Амазон можно отослать физический диск и они его зальют в S3/Glacier

Мой вариант слегка изменённый для того чтобы подошёл ± всем
1) договариваемся с админами и их руководством
2) покупаем небольшой но хорошый старый сервант (например hp cube server) и напихиваем его дисками
3) ставим linux/freebsd/freenas/etc (тут что ближе то и подойдёт)
4) ставим это всё дело на работе в серверной, шифруем от админов и прочих рукоблудов конечно
5) для синхронизации можно использовать syncthing/resiliosync/nextcloud/etc
6) для администрирования этого дела и прямого доступа без открытых портов wg


если повезёт и контора может (как у меня) то даже отдельный белый адрес будет, но и без него неплохо
главное ограничить сетевые аппетиты, в небольшом офисе такой "гость" может и весь аплинк скушать

А что, облака данные не теряют что ли?
UFO just landed and posted this here
Да, они там могут подпортиться\потеряться задолго до локальной копии, ну или криво залиться) Сам сталкивался с амазоновым облаком. Вывод — известен давно, надо бэкапы не только делать но и проверять периодически…

Тогда зачем туда лить? Можно остаться на NAS.

UFO just landed and posted this here

Почему когда говорим про облака, то вы приводите аргумент локальной копии, а когда я говорю про NAS, этот аргумент внезапно не работает?

UFO just landed and posted this here

Я про одновременное использование не уловил.

Ниже правильно написали: вероятность того, что два события случатся одновременно, очень мала и уж точно намного меньше, чем одного.

Тогда зачем туда лить? Можно остаться на NAS.

Вы правда не понимаете или это такой троллинг изысканный? Зачем вообще бекапы делают?

Мы как будто на две разные темы говорим. Я не вижу плюсов облака перед НАСом, вижу минусы: отдаёшь инфу куда-то, что никак не контролируешь.

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

А минус — что любая хакерская собака может его увести кучей способов.

Да, пожар — аргумент, а ограбление — ну можно его поставить куда-то, где его и видно не будет.

пусть уводит, данные шифрованные же!
Кажется, вы написали комментарий об отсутствии контроля в облаке под статьей, которая более чем наглядно говорит и об отсутствии контроля в NAS.

Кроме того, я не заметил, чтобы кто-нибудь из ваших оппонентов противопоставлял облака и NAS. А некоторые комментарии прямо говорят о подразумеваемом их одновременном использовании.

Я про одновременное использование не уловил.

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


ну может тогда WD пора предоставлять синхронизацию с облаком для надёжности. Пусть даже за доп. плату как опцию. Многие пользователи не очень опытны чтоб настраивать бэкапы.
(Промахнулись веткой) Это, кстати, вариант идеальный. Для пользователя — скорость и комфорт локальных данных + сохранность ценных (да хоть выборочно, по фильтру), а для компании — плавный переход на SaaS.
А минусовать того не надо, дело говорит. Только настроить всё это дело — отдельная песня.
(Промахнулись веткой) Это, кстати, вариант идеальный. Для пользователя — скорость и комфорт локальных данных + сохранность ценных (да хоть выборочно, по фильтру), а для компании — плавный переход на SaaS.
А минусовать того не надо, дело говорит. Только настроить всё это дело — отдельная песня.


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

хм, я опять веткой не туда. Вроде нажимал «ответить»
А я не понял момент, почему диски в инет светятся? К ним прямой доступ из инета можно открыть минуя прослойку в облаке WD?
У меня хоть и такой Live, но всё это было не нужно и я даже не разбирался как там работает.

Здесь диски в инет не светятся — это либо выдумки пиарщиков WD, либо другие части NAS'а это таки делают, но не суть.
Тут элементарно выполняется GET-запрос:
<img src='http://wdmycloud/api/1.0/rest/language_configuration?#{params}' />
Грубо говоря, ничего не мешает мне или комментирующим запустить эксплоит прямо здесь. Светит в интернет браузер компьютера. От выше указанного спасёт лишь uMatrix, настроенный на блокировку по умолчанию изображений (и вообще всех запросов) на сторонние сайты ("3rd party")


PS: Пока я вставлял этот кусок кода, HTML-овский тег code не засчитался и я в течении 10-ти секунд тут таки ненароком вставил такое "изображение" с запросом эксплоита. На что мне uMatrix показал:



Зеленое — разрешено, красное — заблокировано.

Т.е. пользователи сами в браузерах открывали какие-то ресурсы, где были вредоносные вызовы API? В этом случае понятно как доступ в сеть, где диск, получился.
Но что за сайты все начали массово открывать, что в один день у всех проблемы?

Или я неправильно всё понял?

А эти правки languageConfiguration.php персистентые? Или будут слетать после каждой перезагрузки? А то у меня настройки доступа по webdav слетают после каждого отключения электричества.

Нет, всё слетает при перезагрузке, т.к. файлосистема на самом деле read-only, а все изменения в идут оверлей (в оперативку).

Челу было лень писать, как вносить правки непосредственно в прошивку (в файл image.cfs (Образ диска, SquashFS))

Для двухдисковых WD'шек:

dd if=/dev/mtdblock3 of=rootfs.cfs
unsquashfs rootfs.cfs rootfs
# [ Вносим правки ]
mksquashfs ./rootfs rootfs.cfs -comp xz
dd if=/dev/zero of=/dev/mtdblock3
dd if=rootfs.cfs of=/dev/mtdblock3

У однодисковых rootfs.cfs лежит на диске, также, в третьем разделе (/dev/sda3, ext3), в папке /boot

  • Пишу по памяти. Могу ошибиться.

UFO just landed and posted this here

Извиняюсь, путаю с другой уязвимостью в WD MyCloud. Там ОСь работает в режиме оверлея в оперативке.
MBL как и самый первый MyCloud Gen1 хранит операционку на норамльном разделе с Ext3.

Живём не WD единым, фейлы с потерей данных или предпосылками случаются легко.
1. Замяло контакт одной из дифференциальных пар в разъёме кабеля к дисковой полке, результат — небольшое количество ломаных файлов. Благодаря тому, что ведётся контроль целостности, удалось быстро обнаружить и восстановить повреждённое содержимое. Голый RAID-6 от этого не спас.
2. Видюха своим кулером снесла SMD-компоненты на SAS-контроллере (пластиковый кожух видюхи слегка деформировался и крыльчатка вентилятора всё-таки достала SAS-контроллер). Заменил на резервный, данные не пострадали.
3. Нестабильный контакт платки датчика температуры внешнего воздуха сервера. Вентиляторы раскручивались на максимум (12k RPM), что создавало ощутимые вибрации и могло довольно быстро прикончить диски в корзине.
4. Перенапряжения в сети. После гроз несколько раз выгорало оборудование, но данные оставались целыми. У знакомых после недавней аварии на подстанции выгорели ноуты/компы.

Ещё были прочие разные физические повреждения контроллеров, кривые прошивки контроллеров.

В общем, «надёжная и проверенная» прошивка вендора, конечно, снижает риски, но только часть, всё равно остаётся много других факторов, которые могут оставить без бекапа.

Несколько частных выводов:
1. Избегать голого RAID, тому много причин. Использую ZFS, для бекапов — zraid2, плюс — базы хешей файлов для контроля целостности между холодными хранилищами.
2. По возможности, стараюсь иметь одно или несколько холодных хранилищ, физически отключенных от электросети, не смотря на всякие реле напряжения и ИБП.
3. Очевидно, что для данных, которые не хочется потерять, нужно иметь минимум три надёжные копии. Интересно, сколько народу считает это избыточным?
4. Очевидно, что нужно смотреть спеки на диски, причём со здравым скептицизмом. Самое банальное — сборка массивов из десктопных дисков или даже «NAS»-дисков, но без учёта их реальных возможностей (работа 24/7, работа в многодисковых массивах, объёмы нагрузки). Могут жить десятилетиями, но можно кончить несколько ящиков дисков за короткое время, если ингорить их реальные возможности.
5. Если брать ленты, то иметь минимум по два привода на тип. Записанное на одном приводе может больше нигде не читаться. Сдохнет привод, прощайте бекапы.

Бекапы сейчас делать очень просто. Есть куча удобного софта, всё легко и просто масштабируется. Даже если нужно поставить сотню дисков, то б/у серверы и дисковые полки стоят копейки (полки на 15 дисков покупал по 2 тыс. руб., даже сейчас сервер или полку на 12-15 дисков можно найти за 4..12 тыс.), есть ящики от Supermicro, куда можно запихать тихие вентиляторы, БП от seasonic и иметь дома компактное тихое хранилище приличного объёма. Для мелких частных хранилищ на десяток-другой терабайт вообще достаточно десктопа и 2-4 диска в zmirror. Сами диски, конечно, подорожали, это печально. Остаться без значимых данных тоже печально. Даже одна «лишняя» offline-копия на дешёвом диске лучше её отсутствия.
UFO just landed and posted this here
Не бессмысленно. Домашнее хранилище — это лишь один из уровней многоуровневой организации бэкап-пространства. Чтобы иметь возможность восстановить случайно стертый файл, вам не нужна географическая разнесенность.
Наличие любого бекапа — уже хорошо. Дополнительный плюс локальной копии — можно пользоваться быстрым подключением. Лезть через инет обычно сильно медленнее, бывает проще притащить на диске, если объём большой.
3. Очевидно, что для данных, которые не хочется потерять, нужно иметь минимум три надёжные копии. Интересно, сколько народу считает это избыточным?

Имею 4 копии ;)
1. Второй локальный диск в ноуте.
2. Внешний USB-диск
3. Домашний бэкап-сервер (не NAS, но не суть)
4. Облако
Бекапы сейчас делать очень просто. Есть куча удобного софта, всё легко и просто масштабируется. Даже если нужно поставить сотню дисков, то б/у серверы и дисковые полки стоят копейки (полки на 15 дисков покупал по 2 тыс. руб., даже сейчас сервер или полку на 12-15 дисков можно найти за 4..12 тыс.), есть ящики от Supermicro, куда можно запихать тихие вентиляторы, БП от seasonic и иметь дома компактное тихое хранилище приличного объёма. Для мелких частных хранилищ на десяток-другой терабайт вообще достаточно десктопа и 2-4 диска в zmirror. Сами диски, конечно, подорожали, это печально. Остаться без значимых данных тоже печально. Даже одна «лишняя» offline-копия на дешёвом диске лучше её отсутствия.


конечно легко и просто. Каждый фотограф или домохозяйка с этим легко справятся. Купят полки, сотню дисков, бу серверы. Им-то всё-равно скучно и нечем заняться
А в чём проблема-то? В комп лишний диск поставить? Воткнуть внешний диск по USB? Есть готовые решения от Synology, QNAP и прочих. Из этого списка найдётся что-то с чем домохозяйки разберутся, а фотографы — тем более. Каких-то особых проблем с масштабируемостью тут нет. Видел ролик одного фотографа, он хранил бекапы на внешних USB-дисках, их было несколько контейнеров. Плотность хранения, нужно сказать, очень хорошая, удобство — так себе, но если припрёт — будет шанс восстановиться. Полно софта, доступного для понимания. Конечно, когда хочется и дёшево и сразу много, то придётся немного вникнуть в тему. Б/у серверное железо стоит очень дёшево, и да, у него хватает своих особенностей, тут уже не каждая домохозяйка справится, но я к этому и не призываю. Тем не менее, петабайт+ хранилище будет стоить дёшево, основной затык — подорожавшие диски, всё остальное — не проблема. Если домохозяйке вдруг нужно бекапить петабайты, то даже такие хранилища не займут уж очень много места (коробкам с сезонной обувью бывает нужно больше места), думаю, что обладатель такого объёма данных найдёт себе подходящий софт. В бекапах обычно ограничивает лень и простое непонимание рисков потери данных, а не сам статус домохозяйки или фотографа.
В бекапах обычно ограничивает лень


а почему вы не пломбируете себе зубы сами? Не можете разобраться в этом? Лень? А почему вы не выращиваете пшеницу самостоятельно, потом делаете из неё муку, а потом печёте хлеб сами? Тоже лень? )
лень — это двигатель прогресса. Те кому не лень, мыслят обычно непрактично сложно.

Воткнуть внешний диск по USB? Есть готовые решения от Synology, QNAP и прочих.


как это работает? Нужно купить несколько дисков (для избыточности), и потом вручную периодически перегонять данные на них? Ну как максимум наверное есть готовое ПО от вендоров для синхронизации. Но придётся повторить операцию для нескольких дисков.
Да, периодически перегонять данные на несколько дисков — это так и работает, технологии и удобство могут быть разными, но суть такая. У разных способов бекапа свои плюсы/минусы.

Вообще, это классический путь — просрать единственные данные -> понять, что нужно бекапиться. Кому-то везёт и этого становится уже достаточно, ибо просрать всё одновременно с бекапом менее вероятно. Зато тут начинаются обиды, как сейчас вышло с WD, когда всё-таки херятся и бекапы (или вообще первичные данные). Кто-то будет делать дополнительно один бекап, это ещё сильнее снизит риски. Кто-то сменит вендора, кто-то — пофиксит прошивку.

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

На счёт лени. Хранилища и серверы хороший пример. Оно сложное и дорогое, много избыточности, можно всё очень сильно упростить и сделать бы в разы дешевле. Однако, приходится за эту дорогую избыточность платить, т.к. отказы выходят дороже железа и его эксплуатации. Например, SAS-диски с двумя портами, подключенные через разные контроллеры, к разным хостам с избыточными подключениями к разным коммутаторам. И сами диски зеркалятся (вместо более экономичных RAID-60), и сервисы дублируют друг друга, и даже сами дата-центры. Это не из-за лени, а из-за целесообразности, деньги приходится считать и риски взвешивать.

Есть USB-диски, если их не бить, то для многих домашних случаев оно достаточно надёжно (особенно, если иметь несколько копий). Кому-то нужно часто делать бекапы, тут может быть удобнее NAS или облако. Для этого всё равно должен быть какой-то стимул, минимальное понимание рисков.
Это не из-за лени, а из-за целесообразности, деньги приходится считать и риски взвешивать.


ну круто конечно. А что у вас за данные? Просто интересно что такое важное что стоит такой мороки)

Кому-то нужно часто делать бекапы, тут может быть удобнее NAS или облако


облако проще. А NAS вот уже есть примерчик) Если все NAS-ы так будут работать то бэкапов не настачишься.
Я достаточно ленивый) Дома главный бекап — фотки. Думаю, что у многих всё аналогично, наибольшую ценность представляет свой собственный контент: фото/видео, подборки музыки, что-то из фильмов, какой-то софт, т.е. накопленное своими силами. Всё это нет необходимости особенно часто бекапить. Плюс сетевого хранилища — в отсутствии необходимости лезть за USB-диском и подключать его, но когда-то такого решения было достаточно. Главное — вообще иметь холодные резервные копии, даже если носитель не верх надёжности. Факапы и наглое забивание на юзеров бывают у всех, WD ничем тут не выделился. Вроде бы редко отказы случаются, но даже на бытовом уровне за месяц уже насмотрелся взрывов подстанций из-за жары или грозы (пострадало железо у людей, которых знаю). У бизнеса — свои интересы. Кто-то экономит на спичках, кто-то красуется своими hi-end СХД, кому-то похрен на даунтайм, а для кого-то это очень больно, вот и раскошеливаются на специалистов + оборудование.
Дома главный бекап — фотки


фотки могут весить много. Ну наверное даже терабайты. Но сколько это должно быть данных чтоб покупать полки, б.у. сервера и вот это всё?

по простым прикидкам 100 тысяч фоток по 10Мб каждая будут ~1Тб
но это уже дохрена фоток, столько может быть у фотографов
Тут всё индивидуально. Вопрос больше не в объёме, а в количестве имеющихся дисков. Если нужно просто поставить больше 2-3 дисков, то сервер или полка может быть банально дешевле внешнего USB-бокса, тем более — готового NAS. Тут на выбор — классический десктоп или сервер/полка. Если использовать SAS-диски, им нужен свой контроллер и кабели, готовый сервер со всем этим стоит дешевле, чем отдельно покупать один только контроллер + кабели. Форм-фактор — есть любой и у десктопов, и у серверов, и у готовых NAS, кому что больше подходит. По объёму, один внешний USB-диск на 10 ТБ заменяет дисковую полку с 15-ю SAS-дисками на 900 ГБ с ZFS (zraid3). Для редкого бекапа фоток один диск занимает на порядок меньше места, не говоря о шуме, а вот для работы с RAW video полка будет интереснее, особенно если докинуть оперативы и кэша на SSD. Скорость последовательного чтения с полки будет очень высокой (2 ГБ/с), а у одного 10-ТБ диска — около 250 МБ/с. Для бекапа — проверка целостности 10 ТБ займёт 1.5-2 часа против 11+ часов. Высокая производительность — прикольно, но не всем оно так уж и нужно.

У QNAP/Synology своих дыр/проблем хватает.

Косячат все, и производители HDD/SSD, и вендоры чипов, серверов/хранилищ, и разработчики софта, и проектировщики, и монтажники, и эксплуатация. Вообще все, бывает очень по-чёрному. Энтерпрайз бывает ничем не лучше хоум сегмента, зато сильно дороже и больнее. Тем не менее, можно добиваться высокой надёжности и доступности. В данном случае, если на NAS от WD хранился бекап, то его можно вернуть обратно, с оригинала (попутно пофиксив уязвимость). Девайс обеспечивал избыточность до отказа, девайс может обеспечивать избыточность после отказа, свою функцию он выполнял и может продолжить выполнять, единичный отказ — это ожидаемо (впрочем, массовый отказ идентичных конфигураций — тоже). В этом суть резервирования. В больших системах со временем становится видно статистику отказов, а вот дома — не то количество железа, один сдохший диск может дать 100% безвозвратных потерь, но тут сложность/стоимость бекапа низкая, вопрос — в мотивации.

Вы свою репутацию за последние годы растеряли... Другое дело, что ваши конкуренты ее растеряли ещё больше)

Наконец-то кто-то узнает какое УГ этот ваш WD. Всегда удивлялся тому как юзеры добавляют в хвалебный чан с WD свою щепотку восхищения ​

WD платят пиарщикам больше чем инженерам и программистам. Это было понятно ещё середине в нулевых. А сегодня всё блоггерское ИТ-сообщество живет рекламой от WD. Обращайте внимание на невзрачные Kioxia и Intel. Их циферки хоть и не блещут маркетинговыми перьями, но не врут. SSD от Toshiba на 250Gb будет жить даже после 17-кратного превышения TBW ​

WD же всегда было враньём. Недавно я наступил на грабли: обновил ПО хранилища от WD с 3 версии до версии 5. Без предупреждения исчезла поддержка opkg transmission 🤦​‍♂​. Откатиться себе дороже.

Не верьте этим УГ-шникам.

Если вижу в WD MyCloud вместе exec() стоит exec_runtime() - что то надо править, или этот класс уже валидирует вызовы?

Я кода прошивки не видел. Можете пройти по ссылкам в тему форума и поискать, может он с тех пор описал фикс подробнее.

Какой кусок кода выполняет exec_runtime?

Лежит тут

/var/www/rest-api/api/Util/includes/exec.php

function exec_runtime( $command, &$output = null, &$return_var = null, $escapeCmd = true) {

        global $metachars;

        if ($escapeCmd) {
                //escape shell meta-characters to prevent command injection

                $command = escapeshellcmd($command);

                //escapeshellcmd escapes meta characters within single quotes, we need to remove the backslashes
                //in this case to preserve the original quoted text.

                $quoteCtr = 0;
                if (strpos($command, "'") !== FALSE) {

                        $commandArr = str_split($command);
                        $commandLen = sizeof($commandArr);
                        for ($idx = 0; $idx < $commandLen;  $idx++) {
                                $char = $commandArr[$idx];
                                if ($char === '\'') {
                                        if (!$quoteCtr) {
                                                //start of quoted string
                                                ++$quoteCtr;
                                        }
                                        else if ($quoteCtr) {
                                                //end of quoted string
                                                --$quoteCtr;
                                        }
                                        //remove escape before quote
                                        if ($idx > 0 && $commandArr[$idx-1] == '\\') {
                                                unset($commandArr[$idx-1]);
                                        }
                                }
                                if ($quoteCtr && $char == '\\') {
                                        //remove backslash within quotes only if it preceeds a meta-character
                                        if (($idx +1) < $commandLen) {
                                                //backslash is not at end of command string
                                                if (in_array($commandArr[$idx+1], $metachars)) {
                                                        //char after back-slash is a meta-character. so remove the backslash
                                                        unset($commandArr[$idx]);
                                                }
                                        }
                                }
                        }
                        $command = implode($commandArr);
                }

                //close out single quotes to prevent command injection using an un-terminated quoted string
                if ($quoteCtr) {
                        $command = $command . "'";
                }
        }

    $output = $return_var = null; // $output is getting concatenated.... $return_var for good measure.
    $start = microtime(true);
    $return = exec($command, $output, $return_var);
        $totalTime = microtime(true) - $start;

    \Core\Logger::getInstance()->addCommand($command, $output, $totalTime);

        return $return;
}

Да, в принципе предположение верное, но я бы не рискнул без полного анализа кода говорить "пользуйте!"

Больше всего настораживает витеватость кода и "escapeshellarg" функция, которая судя по описанию уже должна всё экранировать, но тут начинаем убирать обратные черты \\ в отрезке кода ниже. Тем более:

escapeshellcmd escapes meta characters within single quotes, we need to remove the backslashes

В shell внутри одинарных 'кавычек' нет никаких других мета-символов кроме них самих. Какого фига такое описание, что они там внутри делают и почему не в той же функции убирают обратные черты... доверия к коду - ноль. Но существующие эксплоиты такая обработка может тем не менее попортить.

Патч от товарища (пусть я бы чуть по-другому написал) железобетонно проверяет приходящую строку на соответсвие ожидаемому тексту и ничего иного допускать не будет.

Но вообще, я не прочь покопаться и дать подробный ответ. Можете скинуть файлы от веб-интерфейса в личку, если хотите. А то WD уже начинает распространять информацию, мол новый 0day используют (странно, если обсуждаемый выше эксплоит работает)

Я сильно не парюсь, у меня WD наружу ничем не торчит, внутренний бекап файлсеврер, управляемый линухом из внутренней-же сети. Нравится мне первый wdmycloud что там систему можно под себя менять.

Код скинуть могу, в личку простыней? Не вижу возможности файло зацепить.

Образ я брал отсюда, когда с 2 TB на 8 TB мигрировал

https://drive.google.com/drive/folders/1Dv6abMamaoW4AYS4YPtdwdVAP88nUEve

Так это в админке уязвимость, а не в системе?

Кто-то выставлял админку в дикий интернет что ли, или зловред из браузера проникал и сканировал сеть на предмет коробок от WD? Хотя в этом случае можно ещё проверять состояние SSH и отрываться через него по полной программе.

Я просто вырубал апач, потому что эта тварь много памяти кушала, которой там всего 256 МБ.
UFO just landed and posted this here
Sign up to leave a comment.

Articles

Change theme settings