Vlad Ivanov, аппаратно да, не густо, но если берешь на процессоре интел то все что заявлено работает вполне прилично, как минимум то что относится к бэкапам и хранению данных для общего доступа и медиаконтнта. Конечно чудес не бывает, и сетевое хранилище не выйдет истользовать как высоконагруженную базу данных (как очень слабонагруженную - да ;), предназначение не то.
Vlad Ivanov, Sinology ds218, ds718. Настоящие в общем. Несмотря на заявленную поддержку в течение 24часов решил не рисковать, что если например выносной блок питания умрет? пока такой же куплю... данные могут вполне раньше понадобиться.
soft raid. В hardware raid на материнской плате проблем больше чем счастья, разве что специализированный NAS-блок использовать, тот что в серверные стойки встраивается или отдельным модулем стоит. Сам например в синолоджи нас реид1 только ехт4 формат использую, чтобы в случае случаев данные везде прочитать можно было. С бтрфс имел уже танцы с бубном...
а насчет базы данных, рекомендую для майскула automysqlbackup: есть во всех репозитариях линукс, и работает как часы. Дампы по времени можно тоже настроить, если более чем 1 раз в день надо.
btrfs - классно, когда за всем следишь. Ад начинается, когда постаил автоматические снапшоты, например при обновлениях, и забыл. снапшоты забивают свобдное место на диске, и привет: система не загружается от слова совсем. без смартфона, чтобы нагуглить как убить хотя бы последний снапшот освободив место для загрузки, получаешь из компа кирпич. так было у меня например с дефолтной установкой опенсусе. Классная система, пользуюсь до сих пор, но на ехт4 :) и без снапшотов...
сорри, был в оффлайн.
Дуплисити грузил файлы бэкапа с шифрованием по SSH на внешний файлсервер.
Вообщем, были задействованы все вами тут обсуждаемые фичи ;)
Как я уже и говорил, один из файлов инкрементального бэкапа по невыясненной причине оказался испорчен (либо при передаче прошел сбой, либо при записи на диск, скорее второе, но проверка файловой системы на сервере ошибок не показала), и расшифровке не поддавался.
Результат - полное фиаско с откатом до последнего хорошего инк-бэкап, гугл не помог, разработчики просто не успели ответить, хотя если мне не изменяет память кто-то потом на форуме написал что-то типа сорри ман шит хэппенс :)
Стоит заметить что в моем случае это был полный бэкап одной небольшой продакшн-системы, и вариант восстановить только часть файлов не прокатывал.
С БареОс и БэкапПЦ есть (к несчастью;) уже опыт 3х полных восстановлений систем, но к счастью все полностью успешные и быстрые, централизованно с бэкап-сервера
BackupPC:
никакого дополнительного софта на клиенте не требуется, есть дедуп (экономия места на сервере для бэкапа однотипных систем до 70-80 процентов)
все настройки и управление можно делать как в терминале так и в вебморде
инициация бэкапа со стороны сервера, по крону
связь с клиентом по протоколам rsync/ssh, ftp, smb, tar для локальных бэкапов...
BareOS:
нужно устанавливать клиентский софт, но зато
гарантия целостности файлов при передаче и записи на диск (проверка контрольных сумм с обеих сторон)
нет зависимости от доступных на клиенте протоколов, была бы лишь связь с сервером
инициация бэкапа как с сервера, так и с клиента
все настройки и управление можно делать как в терминале так и в вебморде
первичная настройка бареос-сервера ненамного, но сложнее бэкаппц
Субьективно восстановление бэкапа например в backuppc после сбоя быстрее и наверное все же удобнее чем в дуплисити.
Но это мое ИМХО ;)
Был у меня около года/полтора назад случай disaster recovery с duplicity.
Из-за испорченного архива идущего сразу после фуллбэкап месячной давности восстановится до текущего состояния не удалось. Пришлось откатится на месяц назад, и вручную(!) достать только самые важные файлы, роясь в инк-архивах.
После этого случая снес и забыл как страшный сон.
Теперь используем только BareOS для серверов и BackupPC для десктопов/ноутбуков.
С обоими системами опыт хороший, таких казусов никогда не случалось. Профессиональные и надежные. А дуплисити это какбы для самоуспокоения, уж лучше тогда просто рсинк ;)
mxx: насколько я помню, раз в месяц у меня был настроен фулл бэкап, а потом инкрементные. По несчастливому стечению обстоятельств искомые файлы были изменены где-то во второй половине месяца, поэтому с сервера тянулись кроме фулл и почти все инкременты. Обертка тоже была графическая, но я пользовался командной строкой после того как заметил что происходит сбой контрольной суммы одного из инкр.пакетов.
Кроме того, не понравилось в дуплисити что кэш контрольных сумм файлов и бэкап-пакетов занимает много места на клиенте. При большом количестве сохраняемых файлов оказалась весьма ошутима потеря свободного места, а без кэша (например после его удаления) - бэкап очень медленный... и управление восстановлением с клиента, а не с сержера, накладывает свой отпечаток: если нет сервера, а только NAS где-то, то и так сойдет, в противном случае просто неудобно и очень медленно.
По опыту, ему далеко до энтерпрайза. Теперь критичные данные я бы ему не доверил.
использовал тоже до определенного времени. с аплоадом по ssh/scp. все вроде ровно и красиво, только когда понадобилось восстановление пары файлов из бэкапа, дуплисисити потянул всю эту радость обратно, и на одном попавшемся битом пакете заткнулся намертво. Дальше только танцы с бубном и восстановление руками с поиском по каждому из инкремент-пакетфайлов.
В общем, не рекомендую - одного такого случая дизастер рекавери мне хватило навсегда.