Кстати, раз уж зашла речь о бэкапах, подскажите пожалуйста, настолько

правильно я делаю:
в системе есть 4 диска:
0 - ssd с системой
1 - для неважных файлов (wd gold) + отдельный раздел для бэкапа ссд
2 - для важных файлов (wd gold)
3 - для бэкапа второго (wd red)
Я организовал бэкап следующий образом:
Для SSD - настроил rsnapshot с интервалами на специально созданный раздел диска 1
Для диска №2 - вручную, по мере добавления файлов на диск (грубо говоря по ощущению) запускаю скрипт sudo rsync -AogXrvuclHpt --delete /media/good-hdd1/ /media/good-hdd2-backup-hdd1/

Имеют ли данные способы резервного копирования право на жизнь? Диск №3 нигде не используется, к нему (надеюсь) пока что меньше всего вопросов. Немного меня пугали, что мой метод бэкапа системы может быть нестабильным, т.к. рснапшот не копирует некоторые файлы целиком, а просто оставляет ссылки на них и потом это может аукнуться при восстановлении.
А вы что скажете/посоветуете по этому поводу?

Вопрос первый. Что будет если сервер физически сгорит при пожаре после чего его зальют водой при тушении?

всё/что-то потеряется с вероятностью 30-40%

Это допустимо?

Рсинкать раздел это весело, почему не выбрали просто зеркалирование?

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

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

возгорание здания вы что не рассматриваете?

Я про рейд1, к примеру, физический

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

ВераКрипт + облако для критичных данных вполне отличный бюджетный метод....

Норм! Для полного счастья рсинкайте самое важное на другой физ.сервак

не совсем я доверяю рейдам (хотя на старте хотел его сделать, в убунту чате отговорили), учитывая что они постоянно работают с диском. в моём случае третий диск 90+% времени просто отдыхает в системе. да и физический рейд стоит денег

Ты мучаешь рсинком диски только, как выше сказали, рейд куда лучшее решение...

ну криптовать мне их не особо интересно, тут скорее вопрос выхода железа из строя, ибо один wd red у меня так уже слетел (его уже в системе нет)

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

А смысл рейда (тем более программного), если я запускаю рсинк не чаще 1-2 раз в месяц?

Тогда для очень важных и редко изменяемых данных сделай бекап в облако....

там этих данных около 1тб только сейчас наберётся, дорого. я сервер собирал собственно потому, что не нравится идея подписок/аренды чего либо

Яндекс - 10г Гугол - 15г Кто-то там еще - Хг Выбирай, деняг они не просят, а вот от головной боли при потере избавят...

Бэкап в том же месте хранения (ЦОД/стойка/офис/квартира) - это не совсем бэкап. Потому что если внезапно случится проблема - он может быть потерян вместе с основной копией.

начало 2000-ных, европа, небедная конторка сервак HP типа tower еженедельно вручную делаются бэкапы особо важных данных на jaz "дискету" коробка с jaz дискетами с бэкапами лежит сверху сервера, других бэкапов нет ночью происходит небольшой пожар в комнате где стоял сервер ......

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

Главный вопрос, на который нужно ответить - стоит ли такое (небольшое) уменьшение риска потери данных потраченных денег и усилий? Если да - ну что ж, пожалуйста.

Ну как небольшое.. Я таким образом заменил один из парных дисков (если не ошибаюсь, основной), который вышел из строя. После этого его успешно за 300р починил и продал, но всё же данные были очищены

Чтобы не получить одинаково удаленный/зашифрованный файл в бэкапе и в защищаемой системе - хорошим правилом будет организовать доступ так, чтобы защищаемая система не могла писать в хранилище бэкапов, а копирование инициировалось со стороны бэкап-агента (сервера)

Хм, звучит интересно. А как это реализовать, учитывая что оба диска подключены к одному серверу/ОС?

Это частный случай. Он никак не определяет вероятность. Активное зеркало - это вообще не бэкап, по определению, т.к. данные на нем не только одновременно пишутся на два диска, но и одновременно изменяются/удаляются.

У меня не активное зеркало. Руками иногда rsync запускаю

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

Тогда по большому счёту без разницы.

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