16.02.2018 07:49, Victor Wagner пишет: > В Thu, 15 Feb 2018 22:59:07 +0300 > artiom <artio...@yandex.ru> пишет: > >> Подскажите, чем возможно выполнять резервное копирование нескольких >> машин по сети, чтобы условия ниже были удовлетворены. >> >> Склоняюсь к следующим вариантам: >> >> - Bacula. >> - BackupPC. >> - Решения на базе rsync. >> >> Изо всего работал только с rsync, о Bacula имею представление, а >> BackupPC мне неизвестен. >> >> Резервное копирование хочу выполнять на центральное хранилище, с >> FreeNAS. Основные машины - PC с Debian и ноут с Debian. >> Ноут преимущественно подключен через Интернет, PC в локальной сети. > > Я использую надстройку над rsync, называющуюся rsnapshot. > Бэкаплю таким образом и домашнюю машину на USB-диск и виртуалку на > хостинге на домашную машину (по расписанию) > Да, я помню, вы её предлагали, когда я ещё бэкапилку для одной машин делал. Я тогда rdiff-backup выбрал, но сейчас бы остановился на rsnapshot. Тем не менее, доделок много придётся сделать. Для чего мне реализовывать функционал Bacula самому? Какие плюсы есть у rsnapshot? Кроме того, rsync использует жёсткие ссылки, не на всех ФС есть. Да, возможно извратиться, но зачем?
>> Также, в перспективе, могут резервироваться машины с Windows и MacOS, >> возможно Android планшет. > > Вот windows rsync-ом не забэкапишь. Windows я в свое время бэкапил > ntfsclone способом "перегрузился в linux, создал клон". Но это для > ситуации когда пользовательские данные в ней не хранятся. > А может всё-таки Bacula, NextCloud, etc.? >> На Debian-based машинах хочу резервировать конфигурацию в /etc и >> выбранные пользовательские данные. > > Меня в свое время убедили что не надо экономить те считанные гигабайты, > которые занимает /usr и бэкапить и ее тоже. Чтобы потом после > восстановления не разбираться если версии конфигурации в /etc остались > от чуточку более старых пакетов, чем поставились из дистрибутива при > восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr). Как минимум, две машины (плюс, ещё /opt). В /usr я руками ничего не правлю обычно (за крайне редким исключением для Oracle Java на рабочей машине). /var ещё надо бэкапить. Но /usr для чего? > > В общем, анализировать бэкапные решения надо начинать не с "где > хранить" и "какой транспорт использовать" а с "как будет выглядеть > процедура восстановления". Причем в двух вариантах > Да, вообще явного анализа восстановления я не провёл. Неявно, подразумеваю, что буду переустанавливать систему и накатывать данные, а не образ. Т.е., мне не требуется "полный бэкап", как это делают с большим парком машин. > 1. Сдох жесткий диск, вставляем новый > 2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный > файл, который еще в прошлую субботу точно был. > > Вот по части второго решения на базе rsync вне конкуренции. > А Bacula или OwnCloud чем хуже? Ещё несколько пунктов для которых процесс восстановления может различаться: 3. Файл менялся несколько раз, git не было (пусть, это конфиг). Надо восстановить одно из промежуточных состояний. 4. Большое количество пользовательских данных оказались повреждены (не ОС, с ней всё в порядке, а то, на что пользователь имеет права). 5. Требуется восстановить часть данных с одного устройства на другом (с целью синхронизации, например). >> >> Резервное копирование хотелось бы выполнять: >> - По расписанию. >> - По запросу. >> - При пропуске предыдущего. >> >> Условия: >> >> - Все каналы должны быть зашифрованы. >> - Копирование не должно занимать много времени (используется >> Интернет). >> - Должна быть потенциальная возможность репликации в облако (куда, >> пока не знаю, потому должна быть возможность гибко настроить) с >> шифрованием бэкапов. > > C шифрованием каналов и репликацией в облако вопрос такой - вот у вас > сдох жесткий диск со всеми ключами. Вам надо восстановиться из бэкапа. > Каким образом вы будете восстанавливать доступ к тому месту, где лежит > бэкап, для того чтобы его достать? Обеспечивает ли применяемый в таком > случае способ аутентификации надежную защиту ваших данных от сценария > "кто-то прикинулся вами, сломавшим жесткий диск"? > > Опять же шифрованные бэкапы в облаке обычно не слишком удобны для > второго из вышеописанных сценариев: > > либо для того, чтобы достать один файл вам нужно скачивать весь бэкап > (а то и цепочку инкрементальных до последнего полного), либо слишком > много метаинформации доступно владельцу облака (а также > правоохранительным органам страны, где расположен этот облачный сервер > и хакерам, взломавшим облачного провайдера). > > Собственно поэтому я бэкаплюсь на внешний диск, лежащий в тумбочке. Там > все понятно с авторизацией доступа - она физическая. > > в > >
