Здравствуйте, paucity, Вы писали:

P>Здравствуйте, swame, Вы писали:

S>>Купил в 2017 NAS QNAP на 4 диска за 20+ т.р., использовал как Media Server,
S>>через лет 5 он перестал добавлять в хранилище файлы через свой интерфейс ,

P>И че, даже не попытался по ftp или по http в любом интернет броузере подцепиться напрямую по IP-шнику?

P>Чтоб понять это приложение/аддон Media Server'а поломалось или сам nas?

Nas работает, медиасервер работает, не работает файловый менеджер на загрузку файлов на NAS.

S>>как это все чинить ХЗ, я не линуксоид, сколько времени потребует разобраться не представляю.

P>ТС, я так понял, вообще сам собирается nas поднимать, наверняка с простым интуитивно понятным интерфесом разберётся

Интерфейс то просто и понятный, только в нем то это не работает, то это.
И с этим всем надо ковыряться неопределенное количество времени.
Каждую неделю какие-то бесполезные обновления прилетают.
А ТС спрашивает как "не париться"

Здравствуйте, cppguard, Вы писали:

C>Всю сознательную жизнь считал, что можно создать RAID1, RAID5 и т.д. и хранить там данные, которые очень важны.

C>Существует вообще способ организовать хранение данных и не париться?

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

На самом компе естественно рейд1 из любых дисков, даже пусть ssd — для важной информации. Они стоят ничто, и чтобы 2 накрылось одновременно это невероятное событие (лучше брать из разных партий и разных магазинов... накрываются обычно те что были с проблемами и обычно в самые первые недели — бракованные или уронили контейнер при перевозке). Но для совместимости лучше брать одинаковые диски, вообщем в разных магазах и чуть со сдвигом по времени купить тот же девайс, ну а первый купленный жестко протестить пару недель, чтобы наработал на проблемы если есть. У SSD — там проблемы в одинаковых действиях, если в прошивке баги, то если 2 девайса напорятся на это одновременно, то рейда 1 как бы и небыло.

Рейд1 из 2.5" ноутбучных hdd — я предпочел другим вариантам (для хранения данных). Ноутбучные диски должны выдерживать удары, вообщем их делают более живучими. Они тихие, но увы естественно относительно медленные, но для сохранения данных скорее топ — с них еще и восстановить можно, обычно диски не убиваются что все потеряно(а с SSD обычно все потеряно).

Здравствуйте, swame, Вы писали:

S>... то это не работает, то это ...

У Synology надо было nas брать

Здравствуйте, Bill Baklushi, Вы писали:

BB>SSD деградируют всегда, за счет утечки заряда.
Если без питания лежат на полке. Время от времени втыкать в комп.

Здравствуйте, Bill Baklushi, Вы писали:

BB>L.K.:

LK>>+ ручной бэкап на офлайновый носитель (карманный SSD).
BB>SSD зачеркнуть. Известно, что SSD деградирует, находясь в оффлайне. Для этой цели лучше использовать старые добрые HDD.

это точно правда ?
у меня есть ssd которые я не использовал 2 года и данные целые

BB>>SSD зачеркнуть. Известно, что SSD деградирует, находясь в оффлайне. Для этой цели лучше использовать старые добрые HDD.
S>это точно правда ?
S>у меня есть ssd которые я не использовал 2 года и данные целые

Хорошая постановка вопроса

Достоверно известно, что ячейки памяти деградируют от количества циклов перезаписи (стирания)
Причём изначально у памяти только с завода уже есть плохие ячейки
Они выдают случайные значения во время чтения
Но данные будут целы так как защищены ECC, который может исправить N неверных битов
Соответственно если накопится сбойных битов больше N, то сектор прочитать не получится
Хотя это и не приведёт к выходу из строя всего SSD

Есть качество памяти
У хорошей N превышает количество сбойных ячеек в несколько раз
У плохой всего лишь немного больше — быстрее сдохнет

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

Короче, факт имеет место быть
Но тестов как всегда никто не делал )

sergey2b:

BB>>Известно, что SSD деградирует, находясь в оффлайне.
S>это точно правда ?
S>у меня есть ssd которые я не использовал 2 года и данные целые

Я написал, что деградируют, а не гарантированно дохнут.

Инфа 100% Читал не раз и тут и на IXBT.

BB>Я написал, что деградируют, а не гарантированно дохнут.
BB>Инфа 100% Читал не раз и тут и на IXBT.

Цитата из datasheet на Sandisk NAND:

Data Retention
The data in memory might change after a certain amount of storage time. This is due to charge loss or charge gain. After block erasure and reprogramming, the block might become usable again.

Но это очень обтекаемо и непонятно насколько быстро
Нет графиков и таблиц для разного состояния изношенности ячейки

Здравствуйте, cppguard, Вы писали:

пара внешних ssd на пару тб каждый?

Здравствуйте, cppguard, Вы писали:

C>Существует вообще способ организовать хранение данных и не париться?
Существует.

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

Делать резервные копии. Регулярно. В гарантированно консистентном состоянии. И на лету. Хранить их на дисках рядом (в этой же системе), специально диск для архивов купить. Архивация в локальной системе куда быстрее и эффективнее чем по сети. И параллельно сдвигать на соседние системы. Одна из схем — второй диск для бэкапов на каждой станции и асинхронный обмен между ними через сеть по планировщику. Суть в том, что одного хранилища бэкапов не достаточно. Но сильно лучше, чем ни одного. А на станциях всегда есть возможность воткнуть второй-третий диски.

Не жалеть денег на покупку дисков. Всегда лучше прикупить лишний диск "чтобы был". И размером побольше.
Следить за состоянием дисков (smart, журналы ОС) и своевременно реагировать на проявление проблем, не дожидаясь полного отказа системы.

Здравствуйте, TailWind, Вы писали:

TW>У меня как то было зеркало на рабочем компе
TW>В один прекрасный день SATA кабель отвалился у одного из дисков
TW>Комп загрузился и работал как ни в чём не бывало
TW>Знаете что это значит? Что диски перестали быть синхронными
TW>Больше я на рабочем компе рейдов не делал
И напрасно. Ребилд дисков после сбоя — стандартная операция. Хоть кабель, хоть поверхность и замена участника. В этом и смысл зеркала.
Даже виндовое программное зеркало ребилдится и синхронизирует данные без участия человека. Или, например, контролер intel onboard.

С появлением ssd смысл в рейде сильно нивелирован. Куда удобнее отдельные диски под разные задачи.

A>Всегда лучше прикупить лишний диск "чтобы был". И размером побольше.

Нет. Лучше размером поменьше
Чтобы было поменьше головок, блинов
В идеале 1 блин
Проще найти такое в тонких дисках, если не знаешь как проверить

A>Следить за состоянием дисков (smart, журналы ОС)

Да никто не будет следить за этим
Даже за backup'ами все забывают следить

У меня настроено уведомление на email об успешном или не успешном backup'е
Так вот они одно время перестали приходить (я поменял пароль на сервер)
А я и не заметил

После этого я сделал к backup'у лампочки
После заверения backup запускался скрипт, который по http обращался на мой web server, где я часто бываю, и там взводился флажок, что backup успешен
Если он не взведён допустим неделю, загорается красная лампочка. Вот эта тема работала

TW>Каждый день делаем архив самой главной рабочей папки с текущими проектами и кладём на другой диск компа
TW>Храним архивы за последнюю неделю

Не проще ли использовать готовое решение — VCS (subversion например) для таких целей?

TW>Если вы случайно сами удалите свой файл, или измените код так что уже вернуть обратно нельзя, можно взять этот файл из вчерашнего архива

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

M>Не проще ли использовать готовое решение — VCS (subversion например) для таких целей?

Я бы послушал советы про это
Это облака или на локальном компе?
Если не облака, есть ли возможность резервировать в три разных места?

M>>Не проще ли использовать готовое решение — VCS (subversion например) для таких целей?
TW>Я бы послушал советы про это

хм, неожиданный вопрос (я предполагал, что с системами контроля версий/ревизий все тут в той или иной степени имели дело).
На всякий случай поясню, что я предлагаю VCS именно как инструмент работы с ревизиями рабочих данных в виде append-only истории (вместо ежедневного архивирования "главной рабочей папки").
А не средство backup`а.
Вышеупомянутый subversion сам по себе требует бэкапа (https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.backup).
Для репликации subversion репо есть штатные средства: https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.replication
(на на практике я их не использовал).

Здравствуйте, TailWind, Вы писали:

TW>Нет. Лучше размером поменьше
Чем лучше? На большой диск поместится больше копий с нужной глубиной с разных систем. И вся его работа — принять этот файл. Раз в день и/или неделю, старое удалить.

TW>Да никто не будет следить за этим
TW>Даже за backup'ами все забывают следить
Лень закрой дверь, да. Но планировщик может сам следить за появлением событий в журнале и вызывать действия. А там от уведомлений на почту до дёрганья дашборда состояния компании. Сейчас ещё в тележку модно слать.

TW>>Нет. Лучше размером поменьше
A>Чем лучше? На большой диск поместится больше копий с нужной глубиной с разных систем. И вся его работа — принять этот файл. Раз в день и/или неделю, старое удалить.

Большой диск очевидно опасен тем, что при выходе его строя будет потеряно больше данных.
Поэтому я например больше 2TB не беру (а лучше 1TB).

TW>>Нет. Лучше размером поменьше
A>Чем лучше? На большой диск поместится больше копий с нужной глубиной с разных систем. И вся его работа — принять этот файл. Раз в день и/или неделю, старое удалить.

Ну, представьте диск сдох и вам нужно поменять блок магнитных головок
Если не видели его никогда, посмотрите в google картинках

Допустим их 6. Это будет выглядеть как 3 пинцета таких, которые сами слипаются между собой, а вам нужно надеть их на диски
А если их всего две? Насколько проще работать с ними?
Вероятность успешной пересадки 2х головок выше, а поломки меньше

Если у вас заклинило моторчик у диска
Надо переставлять блины в новый корпус
Если вы сместите их друг относительно друга на несколько градусов, диск работать не будет
В то время как с одним блином таких проблем не будет

TW>>Да никто не будет следить за этим
TW>>Даже за backup'ами все забывают следить
A>Лень закрой дверь, да. Но планировщик может сам следить за появлением событий в журнале и вызывать действия. А там от уведомлений на почту до дёрганья дашборда состояния компании. Сейчас ещё в тележку модно слать.

А кто будет следить за тем, что планировщик работает?
А не перестал, по какой либо причине
Вот какую проблему я пытался описать

Здравствуйте, m2user, Вы писали:

M>Не проще ли использовать готовое решение — VCS (subversion например) для таких целей?

ну допустим проект на сотни гигов. картинки там, видеофайлы. как на это vcs отреагирует?

rm2>ну допустим проект на сотни гигов. картинки там, видеофайлы. как на это vcs отреагирует?

Для каждой ситуации свое решение. Есть и коммерческие VCS, рассчитанные на крупные медиафайлы, и subversion для этих целей тоже нередко используется.
Обычные документы (openoffice/pdf) и изображения (фото) я без проблем храню в SVN, но не в таких объемах (репо <10GB).