Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Backup
75 views
Skip to first unread message
artiom
Feb 15, 2018, 3:00:02 PM2/15/18
to
Подскажите, чем возможно выполнять резервное копирование нескольких
машин по сети, чтобы условия ниже были удовлетворены.
Склоняюсь к следующим вариантам:
- Bacula.
- BackupPC.
- Решения на базе rsync.
Изо всего работал только с rsync, о Bacula имею представление, а
BackupPC мне неизвестен.
Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
Основные машины - PC с Debian и ноут с Debian.
Ноут преимущественно подключен через Интернет, PC в локальной сети.
Также, в перспективе, могут резервироваться машины с Windows и MacOS,
возможно Android планшет.
На Debian-based машинах хочу резервировать конфигурацию в /etc и
выбранные пользовательские данные.
Резервное копирование хотелось бы выполнять:
- По расписанию.
- По запросу.
- При пропуске предыдущего.
Условия:
- Все каналы должны быть зашифрованы.
- Копирование не должно занимать много времени (используется Интернет).
- Должна быть потенциальная возможность репликации в облако (куда, пока
не знаю, потому должна быть возможность гибко настроить) с шифрованием
бэкапов.
- Должно быть простое централизованное управление бэкапами (в идеале,
интеграция в web-интерфейс).
- Минимум ручной допилки и сложной настройки на сервере.
машин по сети, чтобы условия ниже были удовлетворены.
Склоняюсь к следующим вариантам:
- Bacula.
- BackupPC.
- Решения на базе rsync.
Изо всего работал только с rsync, о Bacula имею представление, а
BackupPC мне неизвестен.
Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
Основные машины - PC с Debian и ноут с Debian.
Ноут преимущественно подключен через Интернет, PC в локальной сети.
Также, в перспективе, могут резервироваться машины с Windows и MacOS,
возможно Android планшет.
На Debian-based машинах хочу резервировать конфигурацию в /etc и
выбранные пользовательские данные.
Резервное копирование хотелось бы выполнять:
- По расписанию.
- По запросу.
- При пропуске предыдущего.
Условия:
- Все каналы должны быть зашифрованы.
- Копирование не должно занимать много времени (используется Интернет).
- Должна быть потенциальная возможность репликации в облако (куда, пока
не знаю, потому должна быть возможность гибко настроить) с шифрованием
бэкапов.
- Должно быть простое централизованное управление бэкапами (в идеале,
интеграция в web-интерфейс).
- Минимум ручной допилки и сложной настройки на сервере.
Павел Марченко
Feb 15, 2018, 3:20:02 PM2/15/18
to
Без допилов только проприетарщина. В остальном Бакула точнее её форк.
15 февр. 2018 г. 22:59 пользователь "artiom" <arti...@yandex.ru> написал:
grey.fenrir
Feb 15, 2018, 3:40:03 PM2/15/18
to
02/15/2018 10:59 PM, artiom пишет:
сейчас состоянии.
часть - всё просто. Если это облачное хранилище - тоже просто, но
вероятнее всего медленно.
> - Должно быть простое централизованное управление бэкапами (в идеале,
> интеграция в web-интерфейс).
вебморду к этому тоже пилили, но я не проверял, мне в терминале проще.
> - Минимум ручной допилки и сложной настройки на сервере.
весьма дружелюбен
ps: Отзывы по borg'у собираю.
---
Тарас aka L0ki
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
borgbackup весьма хорош
> машин по сети, чтобы условия ниже были удовлетворены.
>
> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.
работает на macos, порты на win и android были, не знаю, в каком они
> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.
сейчас состоянии.
>
> - Должна быть потенциальная возможность репликации в облако (куда, пока
> не знаю, потому должна быть возможность гибко настроить) с шифрованием
> бэкапов.
смотря что в облаке. Если в облако есть возможность поставить серверную
> - Должна быть потенциальная возможность репликации в облако (куда, пока
> не знаю, потому должна быть возможность гибко настроить) с шифрованием
> бэкапов.
часть - всё просто. Если это облачное хранилище - тоже просто, но
вероятнее всего медленно.
> - Должно быть простое централизованное управление бэкапами (в идеале,
> интеграция в web-интерфейс).
> - Минимум ручной допилки и сложной настройки на сервере.
ps: Отзывы по borg'у собираю.
---
Тарас aka L0ki
artiom
Feb 15, 2018, 3:50:02 PM2/15/18
to
> Без допилов только проприетарщина.
Однозначно - нет.
Про всякие Veeam я в курсе: не хочу использовать, т.к. имею
представление о том, что там внутри.
Минимальные допилки и настройку воспринимаю спокойно, главное, чтобы не
пришлось делать своё "кастомное решение".
> В остальном Бакула точнее её форк.
Какой форк?
> <mailto:arti...@yandex.ru>> написал:
Однозначно - нет.
Про всякие Veeam я в курсе: не хочу использовать, т.к. имею
представление о том, что там внутри.
Минимальные допилки и настройку воспринимаю спокойно, главное, чтобы не
пришлось делать своё "кастомное решение".
> В остальном Бакула точнее её форк.
> <mailto:arti...@yandex.ru>> написал:
artiom
Feb 15, 2018, 3:50:02 PM2/15/18
to
Плюсом сюда идут вопросы, по только что узнанному мной OwnCloud/NextCloud.
В чём разница с Bacula? Имеет смысл?
В чём разница с Bacula? Имеет смысл?
Hexawolf
Feb 15, 2018, 4:30:02 PM2/15/18
to
Ещё варианты:
- git-annex - то, что и можно предположить: костыль над гитом.
- SparkleShare - что-то весьма минималистичное
- NextCloud
- SyncThing
- rsync поддерживает использование ssh как транспорт, существуют так же
надстройки разные
Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
абстрактно...
- git-annex - то, что и можно предположить: костыль над гитом.
- SparkleShare - что-то весьма минималистичное
- NextCloud
- SyncThing
- rsync поддерживает использование ssh как транспорт, существуют так же
надстройки разные
Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
абстрактно...
Victor Wagner
Feb 16, 2018, 12:00:02 AM2/16/18
to
В Thu, 15 Feb 2018 22:59:07 +0300
artiom <arti...@yandex.ru> пишет:
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
>
> Склоняюсь к следующим вариантам:
>
> - Bacula.
> - BackupPC.
> - Решения на базе rsync.
>
> Изо всего работал только с rsync, о Bacula имею представление, а
> BackupPC мне неизвестен.
>
> Резервное копирование хочу выполнять на центральное хранилище, с
> FreeNAS. Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.
Я использую надстройку над rsync, называющуюся rsnapshot.
Бэкаплю таким образом и домашнюю машину на USB-диск и виртуалку на
хостинге на домашную машину (по расписанию)
> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.
Вот windows rsync-ом не забэкапишь. Windows я в свое время бэкапил
ntfsclone способом "перегрузился в linux, создал клон". Но это для
ситуации когда пользовательские данные в ней не хранятся.
> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> выбранные пользовательские данные.
Меня в свое время убедили что не надо экономить те считанные гигабайты,
которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
восстановления не разбираться если версии конфигурации в /etc остались
от чуточку более старых пакетов, чем поставились из дистрибутива при
восстановлении системы.
В общем, анализировать бэкапные решения надо начинать не с "где
хранить" и "какой транспорт использовать" а с "как будет выглядеть
процедура восстановления". Причем в двух вариантах
1. Сдох жесткий диск, вставляем новый
2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
файл, который еще в прошлую субботу точно был.
Вот по части второго решения на базе rsync вне конкуренции.
>
> Резервное копирование хотелось бы выполнять:
> - По расписанию.
> - По запросу.
> - При пропуске предыдущего.
>
> Условия:
>
> - Все каналы должны быть зашифрованы.
> - Копирование не должно занимать много времени (используется
> Интернет).
> - Должна быть потенциальная возможность репликации в облако (куда,
> пока не знаю, потому должна быть возможность гибко настроить) с
> шифрованием бэкапов.
C шифрованием каналов и репликацией в облако вопрос такой - вот у вас
сдох жесткий диск со всеми ключами. Вам надо восстановиться из бэкапа.
Каким образом вы будете восстанавливать доступ к тому месту, где лежит
бэкап, для того чтобы его достать? Обеспечивает ли применяемый в таком
случае способ аутентификации надежную защиту ваших данных от сценария
"кто-то прикинулся вами, сломавшим жесткий диск"?
Опять же шифрованные бэкапы в облаке обычно не слишком удобны для
второго из вышеописанных сценариев:
либо для того, чтобы достать один файл вам нужно скачивать весь бэкап
(а то и цепочку инкрементальных до последнего полного), либо слишком
много метаинформации доступно владельцу облака (а также
правоохранительным органам страны, где расположен этот облачный сервер
и хакерам, взломавшим облачного провайдера).
Собственно поэтому я бэкаплюсь на внешний диск, лежащий в тумбочке. Там
все понятно с авторизацией доступа - она физическая.
в
--
Victor Wagner <vi...@wagner.pp.ru>
artiom <arti...@yandex.ru> пишет:
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
>
> Склоняюсь к следующим вариантам:
>
> - Bacula.
> - BackupPC.
> - Решения на базе rsync.
>
> Изо всего работал только с rsync, о Bacula имею представление, а
> BackupPC мне неизвестен.
>
> Резервное копирование хочу выполнять на центральное хранилище, с
> FreeNAS. Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.
Бэкаплю таким образом и домашнюю машину на USB-диск и виртуалку на
хостинге на домашную машину (по расписанию)
> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.
ntfsclone способом "перегрузился в linux, создал клон". Но это для
ситуации когда пользовательские данные в ней не хранятся.
> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> выбранные пользовательские данные.
которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
восстановления не разбираться если версии конфигурации в /etc остались
от чуточку более старых пакетов, чем поставились из дистрибутива при
восстановлении системы.
В общем, анализировать бэкапные решения надо начинать не с "где
хранить" и "какой транспорт использовать" а с "как будет выглядеть
процедура восстановления". Причем в двух вариантах
1. Сдох жесткий диск, вставляем новый
2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
файл, который еще в прошлую субботу точно был.
Вот по части второго решения на базе rsync вне конкуренции.
>
> Резервное копирование хотелось бы выполнять:
> - По расписанию.
> - По запросу.
> - При пропуске предыдущего.
>
> Условия:
>
> - Все каналы должны быть зашифрованы.
> - Копирование не должно занимать много времени (используется
> Интернет).
> - Должна быть потенциальная возможность репликации в облако (куда,
> пока не знаю, потому должна быть возможность гибко настроить) с
> шифрованием бэкапов.
сдох жесткий диск со всеми ключами. Вам надо восстановиться из бэкапа.
Каким образом вы будете восстанавливать доступ к тому месту, где лежит
бэкап, для того чтобы его достать? Обеспечивает ли применяемый в таком
случае способ аутентификации надежную защиту ваших данных от сценария
"кто-то прикинулся вами, сломавшим жесткий диск"?
Опять же шифрованные бэкапы в облаке обычно не слишком удобны для
второго из вышеописанных сценариев:
либо для того, чтобы достать один файл вам нужно скачивать весь бэкап
(а то и цепочку инкрементальных до последнего полного), либо слишком
много метаинформации доступно владельцу облака (а также
правоохранительным органам страны, где расположен этот облачный сервер
и хакерам, взломавшим облачного провайдера).
Собственно поэтому я бэкаплюсь на внешний диск, лежащий в тумбочке. Там
все понятно с авторизацией доступа - она физическая.
в
--
Victor Wagner <vi...@wagner.pp.ru>
artiom
Feb 16, 2018, 12:30:02 AM2/16/18
to
16.02.2018 00:28, Hexawolf пишет:
> Ещё варианты:
>
> - git-annex - то, что и можно предположить: костыль над гитом.
`Git's man page calls it "a stupid content tracker". With git-annex, git
>
> - git-annex - то, что и можно предположить: костыль над гитом.
is instead "a stupid filename and metadata" tracker. The contents of
annexed files are not stored in git, only the names of the files and
some other metadata remain there.`
Насколько проще с этим будет работать, чем с Bacula?
Насколько переносимо и отлажено?
По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
пока не ясно (к примеру, централизованного управления и интеграции в
web-интерфейс там, пожалуй, нет).
> - SparkleShare - что-то весьма минималистичное
Правда, в качестве хранилища по умолчанию - git.
Интересная штука, но у меня пока слабое представление о том, что с ней
возможно сделать, решит ли это мои задачи.
> - NextCloud
Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
почему называется "облаком", легко ли его интегрировать с той же Bacula
(агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
использовать в составе NAS.
> - SyncThing
Сам уже нашёл.
Хотелось бы о нём услышать отзывы использующих.
По мне: весьма интересная штука.
> - rsync поддерживает использование ssh как транспорт, существуют так же
> надстройки разные
>
придётся всё доделывать самостоятельно, а в той же Bacula большинство
функций реализовано и отлажено.
> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
> абстрактно...
>
2. Репликация в выбранное облако (например, dropbox).
Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
Т.к. раньше я ими не пользовался, ничего конкретного про
репликацию/наличие API спросить не могу.
Евгений Кабанов
Feb 16, 2018, 12:50:03 AM2/16/18
to
>> Ещё варианты:
luckybackup - надстройка над rsync, при личном использовании -
никаких нареканий; бэкапит, что скажешь.
--
Евгений Кабанов <evg...@kabanov.tel>
luckybackup - надстройка над rsync, при личном использовании -
никаких нареканий; бэкапит, что скажешь.
--
Евгений Кабанов <evg...@kabanov.tel>
artiom
Feb 16, 2018, 12:50:03 AM2/16/18
to
16.02.2018 07:49, Victor Wagner пишет:
> В Thu, 15 Feb 2018 22:59:07 +0300
> artiom <arti...@yandex.ru> пишет:
>
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
>>
>> Склоняюсь к следующим вариантам:
>>
>> - Bacula.
>> - BackupPC.
>> - Решения на базе rsync.
>>
>> Изо всего работал только с rsync, о Bacula имею представление, а
>> BackupPC мне неизвестен.
>>
>> Резервное копирование хочу выполнять на центральное хранилище, с
>> FreeNAS. Основные машины - PC с Debian и ноут с Debian.
>> Ноут преимущественно подключен через Интернет, PC в локальной сети.
>
> Я использую надстройку над rsync, называющуюся rsnapshot.
> Бэкаплю таким образом и домашнюю машину на USB-диск и виртуалку на
> хостинге на домашную машину (по расписанию)
>
Да, я помню, вы её предлагали, когда я ещё бэкапилку для одной машин делал.
> artiom <arti...@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, создал клон". Но это для
> ситуации когда пользовательские данные в ней не хранятся.
>
>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> выбранные пользовательские данные.
>
> Меня в свое время убедили что не надо экономить те считанные гигабайты,
> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
> восстановления не разбираться если версии конфигурации в /etc остались
> от чуточку более старых пакетов, чем поставились из дистрибутива при
Как минимум, две машины (плюс, ещё /opt).
В /usr я руками ничего не правлю обычно (за крайне редким исключением
для Oracle Java на рабочей машине).
/var ещё надо бэкапить. Но /usr для чего?
>
> В общем, анализировать бэкапные решения надо начинать не с "где
> хранить" и "какой транспорт использовать" а с "как будет выглядеть
> процедура восстановления". Причем в двух вариантах
>
Неявно, подразумеваю, что буду переустанавливать систему и накатывать
данные, а не образ.
Т.е., мне не требуется "полный бэкап", как это делают с большим парком
машин.
> 1. Сдох жесткий диск, вставляем новый
> 2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
> файл, который еще в прошлую субботу точно был.
>
> Вот по части второго решения на базе rsync вне конкуренции.
>
Ещё несколько пунктов для которых процесс восстановления может различаться:
3. Файл менялся несколько раз, git не было (пусть, это конфиг). Надо
восстановить одно из промежуточных состояний.
4. Большое количество пользовательских данных оказались повреждены (не
ОС, с ней всё в порядке, а то, на что пользователь имеет права).
5. Требуется восстановить часть данных с одного устройства на другом (с
целью синхронизации, например).
Коротаев Руслан
Feb 16, 2018, 1:20:02 AM2/16/18
to
В сообщении от [Пт 2018-02-16 08:25 +0300]
artiom <arti...@yandex.ru> пишет:
> > - NextCloud
> Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
> почему называется "облаком", легко ли его интегрировать с той же Bacula
> (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
> использовать в составе NAS.
Nextcloud удобен, но он больше для совместной работы, а не для бекапов,
а облаком он называется потому, что может заменить публичные сервисы
типа Google Drive, Dropbox, то есть работа с файлами, календарь,
веб-почта и так далее. Для файлов у него есть WebDAV и приложения для
Android и iOS.
Можно ещё добавить к списку Minio [1], отличная штука для бекапа (HTTPS,
веб-интерфейс, S3 API), ну и старый добрый FTP(S).
[1]: https://blog.kr.pp.ru/post/2017-07-25/
--
Коротаев Руслан
https://blog.kr.pp.ru
artiom <arti...@yandex.ru> пишет:
> > - NextCloud
> Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
> почему называется "облаком", легко ли его интегрировать с той же Bacula
> (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
> использовать в составе NAS.
а облаком он называется потому, что может заменить публичные сервисы
типа Google Drive, Dropbox, то есть работа с файлами, календарь,
веб-почта и так далее. Для файлов у него есть WebDAV и приложения для
Android и iOS.
Можно ещё добавить к списку Minio [1], отличная штука для бекапа (HTTPS,
веб-интерфейс, S3 API), ну и старый добрый FTP(S).
[1]: https://blog.kr.pp.ru/post/2017-07-25/
--
Коротаев Руслан
https://blog.kr.pp.ru
Павел Марченко
Feb 16, 2018, 1:30:02 AM2/16/18
to
Bareos это форк Бакулы, причем довольно успешный
15 февр. 2018 г. 23:46 пользователь "artiom" <arti...@yandex.ru> написал:
Artem Chuprina
Feb 16, 2018, 2:30:02 AM2/16/18
to
Hexawolf -> debian-...@lists.debian.org @ Thu, 15 Feb 2018 23:28:13 +0200:
> Ещё варианты:
> - git-annex - то, что и можно предположить: костыль над гитом.
> - SparkleShare - что-то весьма минималистичное
> - NextCloud
> - SyncThing
> - rsync поддерживает использование ssh как транспорт, существуют так же
> надстройки разные
Насколько я понимаю, syncthing (пользуюсь) и *Cloud НЕ являются
средствами резервного копирования. У syncthing это прямо так, помнится,
и написано. Это средства _синхронизации_. Они не отличают намеренно
удаленное от продолбанного.
git-annex - не система резервного копирования, а архив с
резервированием. В смысле, для практической пользы от него к нему нужна
дисциплина работы в архиве.
> Ещё варианты:
> - git-annex - то, что и можно предположить: костыль над гитом.
> - SparkleShare - что-то весьма минималистичное
> - NextCloud
> - SyncThing
> - rsync поддерживает использование ssh как транспорт, существуют так же
> надстройки разные
средствами резервного копирования. У syncthing это прямо так, помнится,
и написано. Это средства _синхронизации_. Они не отличают намеренно
удаленное от продолбанного.
git-annex - не система резервного копирования, а архив с
резервированием. В смысле, для практической пользы от него к нему нужна
дисциплина работы в архиве.
Artem Chuprina
Feb 16, 2018, 2:40:02 AM2/16/18
to
artiom -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 08:25:39 +0300:
>> - git-annex - то, что и можно предположить: костыль над гитом.
> `Git's man page calls it "a stupid content tracker". With git-annex, git
> is instead "a stupid filename and metadata" tracker. The contents of
> annexed files are not stored in git, only the names of the files and
> some other metadata remain there.`
> Насколько проще с этим будет работать, чем с Bacula?
> Насколько переносимо и отлажено?
> По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
> пока не ясно (к примеру, централизованного управления и интеграции в
> web-интерфейс там, пожалуй, нет).
Не путаем бэкап с архивом. Для бэкапа не годится.
>> - SparkleShare - что-то весьма минималистичное
> Неслабо минималистичное: свой Dropbox.
> Правда, в качестве хранилища по умолчанию - git.
> Интересная штука, но у меня пока слабое представление о том, что с ней
> возможно сделать, решит ли это мои задачи.
Вообще, должен сказать, что существующие системы контроля версий с
задачами бэкапа довольно плохо совместимы. Поскольку по построению
хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
небольшую выборку, а промежуточные состояния периодически удалять.
>> - NextCloud
> Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
> почему называется "облаком", легко ли его интегрировать с той же Bacula
> (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
> использовать в составе NAS.
>> - SyncThing
> Сам уже нашёл.
> Хотелось бы о нём услышать отзывы использующих.
> По мне: весьма интересная штука.
Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>> - rsync поддерживает использование ssh как транспорт, существуют так же
>> надстройки разные
>>
> Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
> придётся всё доделывать самостоятельно, а в той же Bacula большинство
> функций реализовано и отлажено.
>> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
>> абстрактно...
>>
> 1. Шифрование бэкапов.
> 2. Репликация в выбранное облако (например, dropbox).
> Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
> Т.к. раньше я ими не пользовался, ничего конкретного про
> репликацию/наличие API спросить не могу.
"Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
сети", и "восстанавливать за разумное время" - выберите любые два из
трех. Инкрементальный бэкап, который обеспечивает tar и основные
продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
первое и второй ценой невозможности третьего. Обратный инкрементальный,
как у rsync, второе и третье ценой невозможности первого. Первое и
третье можно делать, гоняя каждый раз полный бэкап.
В многолетней практике (man tar, там эта практика еще со времен бэкапов
на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
по временнЫм характеристикам) обычно устраивают комбинированное решение:
раз в некоторое время гонят полный бэкап, а между ними
инкрементальный. tar вот даже различает дифференциальный (разница с
предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
ни был). Для разумного времени восстановления характерная частота
полного - раз в месяц, дифференциального - в неделю, инкрементального -
ежедневно. В результате получается дорого, но не невменяемо дорого.
Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
понимать, что первое, что тут требуется - это дисциплина. Не такая, как
при работе в архиве, но все же изрядная. "Результатом автоматизации
бардака может быть только автоматизированный бардак." В нее, в
частности, входит периодическая тренировка восстановления из
бэкапа. Потому что очень легко настроить бэкап, из которого потом не
получится восстановиться.
>> - git-annex - то, что и можно предположить: костыль над гитом.
> `Git's man page calls it "a stupid content tracker". With git-annex, git
> is instead "a stupid filename and metadata" tracker. The contents of
> annexed files are not stored in git, only the names of the files and
> some other metadata remain there.`
> Насколько проще с этим будет работать, чем с Bacula?
> Насколько переносимо и отлажено?
> По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
> пока не ясно (к примеру, централизованного управления и интеграции в
> web-интерфейс там, пожалуй, нет).
>> - SparkleShare - что-то весьма минималистичное
> Неслабо минималистичное: свой Dropbox.
> Правда, в качестве хранилища по умолчанию - git.
> Интересная штука, но у меня пока слабое представление о том, что с ней
> возможно сделать, решит ли это мои задачи.
задачами бэкапа довольно плохо совместимы. Поскольку по построению
хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
небольшую выборку, а промежуточные состояния периодически удалять.
>> - NextCloud
> Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
> почему называется "облаком", легко ли его интегрировать с той же Bacula
> (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
> использовать в составе NAS.
>> - SyncThing
> Сам уже нашёл.
> Хотелось бы о нём услышать отзывы использующих.
> По мне: весьма интересная штука.
>> - rsync поддерживает использование ssh как транспорт, существуют так же
>> надстройки разные
>>
> Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
> придётся всё доделывать самостоятельно, а в той же Bacula большинство
> функций реализовано и отлажено.
>> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
>> абстрактно...
>>
> 1. Шифрование бэкапов.
> 2. Репликация в выбранное облако (например, dropbox).
> Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
> Т.к. раньше я ими не пользовался, ничего конкретного про
> репликацию/наличие API спросить не могу.
сети", и "восстанавливать за разумное время" - выберите любые два из
трех. Инкрементальный бэкап, который обеспечивает tar и основные
продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
первое и второй ценой невозможности третьего. Обратный инкрементальный,
как у rsync, второе и третье ценой невозможности первого. Первое и
третье можно делать, гоняя каждый раз полный бэкап.
В многолетней практике (man tar, там эта практика еще со времен бэкапов
на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
по временнЫм характеристикам) обычно устраивают комбинированное решение:
раз в некоторое время гонят полный бэкап, а между ними
инкрементальный. tar вот даже различает дифференциальный (разница с
предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
ни был). Для разумного времени восстановления характерная частота
полного - раз в месяц, дифференциального - в неделю, инкрементального -
ежедневно. В результате получается дорого, но не невменяемо дорого.
Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
понимать, что первое, что тут требуется - это дисциплина. Не такая, как
при работе в архиве, но все же изрядная. "Результатом автоматизации
бардака может быть только автоматизированный бардак." В нее, в
частности, входит периодическая тренировка восстановления из
бэкапа. Потому что очень легко настроить бэкап, из которого потом не
получится восстановиться.
Artem Chuprina
Feb 16, 2018, 2:50:02 AM2/16/18
to
Victor Wagner -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 07:49:34 +0300:
>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>> возможно Android планшет.
> Вот windows rsync-ом не забэкапишь.
Систему нет, а пользовательские данные еще как.
>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>> возможно Android планшет.
> Вот windows rsync-ом не забэкапишь.
Artem Chuprina
Feb 16, 2018, 3:00:02 AM2/16/18
to
artiom -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 08:43:17 +0300:
> Кроме того, 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. Требуется восстановить часть данных с одного устройства на другом (с
> целью синхронизации, например).
При вменяемой системе бэкапа все три пункта - это одно и то же. "Надо
восстановить такое-то место данных за прошлую субботу, а такое - за
позапрошлый понедельник. Ой, нет, за понедельник не то, давайте
попробуем за среду."
Решение с обратно-инкрементальным бэкапом на базе rsync дает этот
результат бесплатно. Остальные - смотреть надо. Dropbox вот, например
(если говорить об облачных средствах, которые вообще-то синхронизаторы,
а не бэкаперы), насколько я вижу интерфейс, дает доступ к версиям
отдельных файлов, а запросить с него состояние папки на позавчера
невозможно. Это как бы не его задача.
Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
машин и есть человек, который регулярно подкручивает эту конструкцию. С
квалификацией админа и наличием _регулярно_ времени на эту работу.
> Кроме того, 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. Требуется восстановить часть данных с одного устройства на другом (с
> целью синхронизации, например).
восстановить такое-то место данных за прошлую субботу, а такое - за
позапрошлый понедельник. Ой, нет, за понедельник не то, давайте
попробуем за среду."
Решение с обратно-инкрементальным бэкапом на базе rsync дает этот
результат бесплатно. Остальные - смотреть надо. Dropbox вот, например
(если говорить об облачных средствах, которые вообще-то синхронизаторы,
а не бэкаперы), насколько я вижу интерфейс, дает доступ к версиям
отдельных файлов, а запросить с него состояние папки на позавчера
невозможно. Это как бы не его задача.
Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
машин и есть человек, который регулярно подкручивает эту конструкцию. С
квалификацией админа и наличием _регулярно_ времени на эту работу.
Михаил Касаджиков
Feb 16, 2018, 5:40:03 AM2/16/18
to
artiom <arti...@yandex.ru> писал(а) в своём письме Thu, 15 Feb 2018 22:59:07 +0300:
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
>
У меня всё кроме /boot — на LVM. При запуске скрипта происходит следующее:
1. создаём lvm snapshot для желаемых разделов;
2. монтируем эти снимки в /mnt/root, /mnt/home и тд.;
3. монтируем сетевое хранилище в /mnt/backup;
4. запускаем backup-manager;
5. демонтируем снимки и хранилище;
6. убираем снапшоты.
Сам backup-manager — обычный bash-скрипт, использующий tar, или dar, который делает:
* добавляет нужные имена архивам;
* следит за созданием master/increment архивов;
* удаляет старые архивы:
* шифрует, при желании, с помощью gpg;
* заливает архивы на удалённый сервер;
* …
На выходе получаем набор архивов, которые нужно последовательно распаковать. Если в компе помер винт — нужно его разметить, создать LVM, разделы, ФС, смонтировать всё это и последовательно распаковать архивы до желаемого момента. Несколько раз уже восстанавливал как отдельные файлы, так и машины полностью.
Пакет в репе так и называется — backup-manager.
--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
>
> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
> Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.
Я использую backup-manager и скрипт-обвязку для LVN snapshot.
> Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.
У меня всё кроме /boot — на LVM. При запуске скрипта происходит следующее:
1. создаём lvm snapshot для желаемых разделов;
2. монтируем эти снимки в /mnt/root, /mnt/home и тд.;
3. монтируем сетевое хранилище в /mnt/backup;
4. запускаем backup-manager;
5. демонтируем снимки и хранилище;
6. убираем снапшоты.
Сам backup-manager — обычный bash-скрипт, использующий tar, или dar, который делает:
* добавляет нужные имена архивам;
* следит за созданием master/increment архивов;
* удаляет старые архивы:
* шифрует, при желании, с помощью gpg;
* заливает архивы на удалённый сервер;
* …
На выходе получаем набор архивов, которые нужно последовательно распаковать. Если в компе помер винт — нужно его разметить, создать LVM, разделы, ФС, смонтировать всё это и последовательно распаковать архивы до желаемого момента. Несколько раз уже восстанавливал как отдельные файлы, так и машины полностью.
Пакет в репе так и называется — backup-manager.
--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
artiom
Feb 16, 2018, 12:50:02 PM2/16/18
to
Спасибо. Посмотрю.
В чём основная разница с Бакулой?
16.02.2018 09:19, Павел Марченко пишет:
В чём основная разница с Бакулой?
16.02.2018 09:19, Павел Марченко пишет:
> Bareos это форк Бакулы, причем довольно успешный
>
>
>
> 15 февр. 2018 г. 23:46 пользователь "artiom" <arti...@yandex.ru
> <mailto:arti...@yandex.ru>> написал:
>
>
>
> 15 февр. 2018 г. 23:46 пользователь "artiom" <arti...@yandex.ru
>
> > Без допилов только проприетарщина.
> Однозначно - нет.
> Про всякие Veeam я в курсе: не хочу использовать, т.к. имею
> представление о том, что там внутри.
> Минимальные допилки и настройку воспринимаю спокойно, главное, чтобы не
> пришлось делать своё "кастомное решение".
>
> > В остальном Бакула точнее её форк.
> Какой форк?
>
> >
> > 15 февр. 2018 г. 22:59 пользователь "artiom" <arti...@yandex.ru
> <mailto:arti...@yandex.ru>
> > <mailto:arti...@yandex.ru <mailto:arti...@yandex.ru>>> написал:
> > Без допилов только проприетарщина.
> Однозначно - нет.
> Про всякие Veeam я в курсе: не хочу использовать, т.к. имею
> представление о том, что там внутри.
> Минимальные допилки и настройку воспринимаю спокойно, главное, чтобы не
> пришлось делать своё "кастомное решение".
>
> > В остальном Бакула точнее её форк.
> Какой форк?
>
> >
> > 15 февр. 2018 г. 22:59 пользователь "artiom" <arti...@yandex.ru
> <mailto:arti...@yandex.ru>
artiom
Feb 16, 2018, 1:00:03 PM2/16/18
to
Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки?
Вопрос по протоколам в том, нужны ли все эти FTPS и прочие в "облаке",
когда NAS может предоставить их отдельно (подняв FTP сервер, например)?
16.02.2018 09:06, Коротаев Руслан пишет:
Вопрос по протоколам в том, нужны ли все эти FTPS и прочие в "облаке",
когда NAS может предоставить их отдельно (подняв FTP сервер, например)?
16.02.2018 09:06, Коротаев Руслан пишет:
artiom
Feb 16, 2018, 1:20:02 PM2/16/18
to
16.02.2018 09:48, kuzminov пишет:
> On 16.02.2018 08:25, artiom wrote:
>>
>>
>>
>>> - SyncThing
>> Сам уже нашёл.
>> Хотелось бы о нём услышать отзывы использующих.
>> По мне: весьма интересная штука.
>>
> Это программа для синхронизации папок, а не резервного копирвания. Очень
>>
>>
>>
>>> - SyncThing
>> Сам уже нашёл.
>> Хотелось бы о нём услышать отзывы использующих.
>> По мне: весьма интересная штука.
>>
> простая и работает как ожидается примерно.
> Версионность неудобная, куча файлов создается с другим именем. Находит
> устройства почти сразу через любое подключение. Постоянно пользуюсь на
> всех компах для синхронизации доков и профиля браузера.
>
В смысле, как находит устройства?
Но я так понял, для моих целей это неприменимо.
> Есть же urbackup с возможностью работать через интернет (с шифрованием),
> поддержой ZFS И btrfs подтомов, дедупликации, создания образов диска
> (под виндой), восстановления поверх голого железа путем загрузки с
> лайфсд. И все просто работает сразу, в отличии от бареос, для которой
> надо скрипты писать либо кучу конфигов в ручную для каждого клиента.
Клиент-сервер, неплохо.
Не вполне понятно, в чём заключается поддержка ZFS подтомов?
В смысле, что она взаимодействует с ZFS и бэкапит только необходимое (к
примеру, работает со снэпшотами)?
Восстановление на голом железе у меня пока не планируется, для меня это
лишний функционал, дедап тоже не уверен, что нужен: его может обеспечить
ZFS, хотя я и не буду его включать с целью экономии памяти.
artiom
Feb 16, 2018, 1:50:02 PM2/16/18
to
> Hexawolf -> debian-...@lists.debian.org @ Thu, 15 Feb 2018 23:28:13 +0200:
>
> > Ещё варианты:
>
> > - git-annex - то, что и можно предположить: костыль над гитом.
> > - SparkleShare - что-то весьма минималистичное
> > - NextCloud
> > - SyncThing
> > - rsync поддерживает использование ssh как транспорт, существуют так же
> > надстройки разные
>
> Насколько я понимаю, syncthing (пользуюсь) и *Cloud НЕ являются
> средствами резервного копирования. У syncthing это прямо так, помнится,
> и написано. Это средства _синхронизации_. Они не отличают намеренно
> удаленное от продолбанного.
>
А разве отличают системы резервного копирования?
>
> > Ещё варианты:
>
> > - git-annex - то, что и можно предположить: костыль над гитом.
> > - SparkleShare - что-то весьма минималистичное
> > - NextCloud
> > - SyncThing
> > - rsync поддерживает использование ssh как транспорт, существуют так же
> > надстройки разные
>
> Насколько я понимаю, syncthing (пользуюсь) и *Cloud НЕ являются
> средствами резервного копирования. У syncthing это прямо так, помнится,
> и написано. Это средства _синхронизации_. Они не отличают намеренно
> удаленное от продолбанного.
>
artiom
Feb 16, 2018, 2:00:02 PM2/16/18
to
16.02.2018 10:55, Artem Chuprina пишет:
> artiom -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 08:43:17 +0300:
>
> > Кроме того, rsync использует жёсткие ссылки, не на всех ФС есть.
>
> Он их использует только на бэкап-сервере. Если же их нет на его ФС, то
> вопрос в непрофильную рассылку :)
>
Да верно, он же дедупликацию на приёмнике таким образом делает.
>
> > Кроме того, 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 для чего?
>
> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
> чистый диск не получится. Придется ставить систему и накатывать
> конфиги. И тут упс... система оказалась поновее, конфиги частично
> несовместимы...
>
более ли менее новая.
> >> В общем, анализировать бэкапные решения надо начинать не с "где
> >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
> >> процедура восстановления". Причем в двух вариантах
> >>
> > Да, вообще явного анализа восстановления я не провёл.
> > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
> > данные, а не образ.
> > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
> > машин.
>
> Практика восстановления показывает, что если бэкапятся настройки
> системы, то лучше бэкапить всю систему. Восстановление работоспособного
> состояния получится на порядок быстрее. Пользовательские данные можно (и
> часто полезно) бэкапить отдельно.
>
Мало того, не всегда мне нужно будет восстанавливать ту же самую
систему: на том же железе и в точности с той же конфигурацией, плюс к
этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
Падение скорости восстановления здесь для меня терпимо.
> >> 1. Сдох жесткий диск, вставляем новый
> >> 2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
> >> файл, который еще в прошлую субботу точно был.
> >>
> >> Вот по части второго решения на базе rsync вне конкуренции.
> >>
> > А Bacula или OwnCloud чем хуже?
>
> > Ещё несколько пунктов для которых процесс восстановления может различаться:
> > 3. Файл менялся несколько раз, git не было (пусть, это конфиг). Надо
> > восстановить одно из промежуточных состояний.
> > 4. Большое количество пользовательских данных оказались повреждены (не
> > ОС, с ней всё в порядке, а то, на что пользователь имеет права).
> > 5. Требуется восстановить часть данных с одного устройства на другом (с
> > целью синхронизации, например).
>
> При вменяемой системе бэкапа все три пункта - это одно и то же. "Надо
> восстановить такое-то место данных за прошлую субботу, а такое - за
> позапрошлый понедельник. Ой, нет, за понедельник не то, давайте
> попробуем за среду."
>
(инкрементальные бэкапы), к тому же, восстановлением таким образом я
пользовался редко.
Хотя, это удобно.
Возможно было заходить в каталоги за день в течение месяца, плюс
использовалось сжатие на базе fuse-compress.
Минус был в несколько сложной настройке. Кроме того, изредка бэкапилка
ломалась, приходилось разбираться (к тому, что не хочется снова делать
своё велосипед, лучше взять промышленно изготовленный).
> Решение с обратно-инкрементальным бэкапом на базе rsync дает этот
> результат бесплатно. Остальные - смотреть надо. Dropbox вот, например
> (если говорить об облачных средствах, которые вообще-то синхронизаторы,
> а не бэкаперы), насколько я вижу интерфейс, дает доступ к версиям
> отдельных файлов, а запросить с него состояние папки на позавчера
> невозможно. Это как бы не его задача.
>
решают другие задачи.
> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
> машин и есть человек, который регулярно подкручивает эту конструкцию. С
> квалификацией админа и наличием _регулярно_ времени на эту работу.
>
artiom
Feb 16, 2018, 2:10:02 PM2/16/18
to
16.02.2018 09:13, Сергей Цаболов пишет:
> Доброе утро!
>
> Я сказал бы что есть довольное хорошее решение
>
> https://serveradmin.ru/backup-linux-servera-s-pomoshhyu-duplicity/
>
Почитал статью, и не понял, что хотел сказать автор.
В начале он rsync упоминает.
Переехал ли он на duplicity, и в чём основная разница с rsync?
> Но я считаю что Bareos это лучшее решение.
>
> Допустим https://time404.ru/1776/
>
> Главное не все так как описывают со старыми версиями было по другому.
>
Да, тут ещё хвалили вот это, как лучшую альтернативу BareOS:
http://www.urbackup.org/
https://blog.kr.pp.ru/post/2017-07-25/
>
> 15.02.2018 22:59, artiom пишет:
>
> Сергей Цаболов,
> Системный администратор.
>
> ser...@art-design.ru
>
> 125009, г. Москва, М. Гнездниковский пер., д. 9, стр. 1
>
> +7 (495) 956-34-79 (доб. 226)
>
> «Арт и Дизайн» - Наш мир ОТКРЫТ Каждому
>
> www.artd.ru <http://www.artd.ru/>
>
> logo <http://www.artd.ru/>
>
artiom
Feb 16, 2018, 2:10:02 PM2/16/18
to
16.02.2018 13:38, Михаил Касаджиков пишет:
> artiom <arti...@yandex.ru> писал(а) в своём письме Thu, 15 Feb 2018
> 22:59:07 +0300:
>
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
>>
>> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
>> Основные машины - PC с Debian и ноут с Debian.
>> Ноут преимущественно подключен через Интернет, PC в локальной сети.
>
> Я использую backup-manager и скрипт-обвязку для LVN snapshot.
> У меня всё кроме /boot — на LVM. При запуске скрипта происходит следующее:
> 1. создаём lvm snapshot для желаемых разделов;
> 2. монтируем эти снимки в /mnt/root, /mnt/home и тд.;
> 3. монтируем сетевое хранилище в /mnt/backup;
> 4. запускаем backup-manager;
> 5. демонтируем снимки и хранилище;
> 6. убираем снапшоты.
>
Сразу нет: LVM только на Linux и то не обязательно, а значит я получаю
> 22:59:07 +0300:
>
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
>>
>> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
>> Основные машины - PC с Debian и ноут с Debian.
>> Ноут преимущественно подключен через Интернет, PC в локальной сети.
>
> Я использую backup-manager и скрипт-обвязку для LVN snapshot.
> У меня всё кроме /boot — на LVM. При запуске скрипта происходит следующее:
> 1. создаём lvm snapshot для желаемых разделов;
> 2. монтируем эти снимки в /mnt/root, /mnt/home и тд.;
> 3. монтируем сетевое хранилище в /mnt/backup;
> 4. запускаем backup-manager;
> 5. демонтируем снимки и хранилище;
> 6. убираем снапшоты.
>
непортируемое решение.
Кроме того, с двухдисковой конфигурацией LVM всё несколько сложнее.
> Сам backup-manager — обычный bash-скрипт, использующий tar, или dar,
> который делает:
> * добавляет нужные имена архивам;
> * следит за созданием master/increment архивов;
> * удаляет старые архивы:
> * шифрует, при желании, с помощью gpg;
> * заливает архивы на удалённый сервер;
> * …
>
Ладно - сервер. С этим всё ok, но клиента привязывать не хочется.
artiom
Feb 16, 2018, 2:20:02 PM2/16/18
to
15.02.2018 23:31, grey.fenrir пишет:
> 02/15/2018 10:59 PM, artiom пишет:
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
> borgbackup весьма хорош
В Automating backups они предлагают написать bash скрипт.
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
> borgbackup весьма хорош
На скринкасте вижу шифрование, простую работу со снимками архивов и
красивую строку прогресса (в принципе, мне не нужна, я хочу запускать
агенты автоматически и не видеть их работы).
В чём ещё принципиальное отличие от rsync?
>>
>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>> возможно Android планшет.
> работает на macos, порты на win и android были, не знаю, в каком они
> сейчас состоянии.
>>
>> - Должна быть потенциальная возможность репликации в облако (куда, пока
>> не знаю, потому должна быть возможность гибко настроить) с шифрованием
>> бэкапов.
> смотря что в облаке. Если в облако есть возможность поставить серверную
> часть - всё просто. Если это облачное хранилище - тоже просто, но
> вероятнее всего медленно.
>
Схема такова:
- Постоянный бэкап на NAS.
- Шифрование.
- Периодическая (раз в месяц, например) загрузка избранных участков в
облачное хранилище.
artiom
Feb 16, 2018, 2:30:02 PM2/16/18
to
16.02.2018 10:39, Artem Chuprina пишет:
> artiom -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 08:25:39 +0300:
>
> >> - git-annex - то, что и можно предположить: костыль над гитом.
> > `Git's man page calls it "a stupid content tracker". With git-annex, git
> > is instead "a stupid filename and metadata" tracker. The contents of
> > annexed files are not stored in git, only the names of the files and
> > some other metadata remain there.`
>
> > Насколько проще с этим будет работать, чем с Bacula?
> > Насколько переносимо и отлажено?
> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
> > пока не ясно (к примеру, централизованного управления и интеграции в
> > web-интерфейс там, пожалуй, нет).
>
> Не путаем бэкап с архивом. Для бэкапа не годится.
>
По каким причинам?
>
> >> - git-annex - то, что и можно предположить: костыль над гитом.
> > `Git's man page calls it "a stupid content tracker". With git-annex, git
> > is instead "a stupid filename and metadata" tracker. The contents of
> > annexed files are not stored in git, only the names of the files and
> > some other metadata remain there.`
>
> > Насколько проще с этим будет работать, чем с Bacula?
> > Насколько переносимо и отлажено?
> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
> > пока не ясно (к примеру, централизованного управления и интеграции в
> > web-интерфейс там, пожалуй, нет).
>
> Не путаем бэкап с архивом. Для бэкапа не годится.
>
> >> - SparkleShare - что-то весьма минималистичное
> > Неслабо минималистичное: свой Dropbox.
> > Правда, в качестве хранилища по умолчанию - git.
> > Интересная штука, но у меня пока слабое представление о том, что с ней
> > возможно сделать, решит ли это мои задачи.
>
> Вообще, должен сказать, что существующие системы контроля версий с
> задачами бэкапа довольно плохо совместимы. Поскольку по построению
> хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
> со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
> небольшую выборку, а промежуточные состояния периодически удалять.
>
так) для внешнего хранения бинарей: они тоже могли реализовать своё
бинарное хранилище, как модуль гита.
> >> - NextCloud
> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
> > почему называется "облаком", легко ли его интегрировать с той же Bacula
> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
> > использовать в составе NAS.
>
> >> - SyncThing
> > Сам уже нашёл.
> > Хотелось бы о нём услышать отзывы использующих.
> > По мне: весьма интересная штука.
>
> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>
Тут бы неплохо прояснить разницу.
Если из бэкапа требуется доставать отдельные файлы, то границу мне
сложно провести.
> >> - rsync поддерживает использование ssh как транспорт, существуют так же
> >> надстройки разные
> >>
> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
> > придётся всё доделывать самостоятельно, а в той же Bacula большинство
> > функций реализовано и отлажено.
>
> >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
> >> абстрактно...
> >>
> > 1. Шифрование бэкапов.
> > 2. Репликация в выбранное облако (например, dropbox).
>
> > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
> > Т.к. раньше я ими не пользовался, ничего конкретного про
> > репликацию/наличие API спросить не могу.
>
> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
> сети", и "восстанавливать за разумное время" - выберите любые два из
> трех.
> Инкрементальный бэкап, который обеспечивает tar и основные
> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
> первое и второй ценой невозможности третьего. Обратный инкрементальный,
> как у rsync, второе и третье ценой невозможности первого. Первое и
> третье можно делать, гоняя каждый раз полный бэкап.
>
Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
(облако).
Шифровать отдельно при хранении в NAS, не требуется.
> В многолетней практике (man tar, там эта практика еще со времен бэкапов
> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
> по временнЫм характеристикам) обычно устраивают комбинированное решение:
> раз в некоторое время гонят полный бэкап, а между ними
> инкрементальный. tar вот даже различает дифференциальный (разница с
> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
> ни был). Для разумного времени восстановления характерная частота
> полного - раз в месяц, дифференциального - в неделю, инкрементального -
> ежедневно. В результате получается дорого, но не невменяемо дорого.
>
построить не сильно напрягаясь?
> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
> при работе в архиве, но все же изрядная.
В плане организации я пытаюсь сейчас всё постепенно рассортировать
(сейчас закончил только с музыкой и видео, проекты в нормальном
состоянии, книги и документы в процессе сортировки).
Поэтому, что бэкапить, я могу сказать.
> "Результатом автоматизации
> бардака может быть только автоматизированный бардак." В нее, в
> частности, входит периодическая тренировка восстановления из
> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
> получится восстановиться.
>
которой постоянно работаешь (в любом случае, восстановление - потеря
времени)?
Artem Chuprina
Feb 16, 2018, 4:40:02 PM2/16/18
to
artiom -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 22:25:22 +0300:
>> >> - git-annex - то, что и можно предположить: костыль над гитом.
>> > `Git's man page calls it "a stupid content tracker". With git-annex, git
>> > is instead "a stupid filename and metadata" tracker. The contents of
>> > annexed files are not stored in git, only the names of the files and
>> > some other metadata remain there.`
>>
>> > Насколько проще с этим будет работать, чем с Bacula?
>> > Насколько переносимо и отлажено?
>> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
>> > пока не ясно (к примеру, централизованного управления и интеграции в
>> > web-интерфейс там, пожалуй, нет).
>>
>> Не путаем бэкап с архивом. Для бэкапа не годится.
>>
> По каким причинам?
Требует архивной дисциплины. Я использовал его, ага.
>> >> - SparkleShare - что-то весьма минималистичное
>> > Неслабо минималистичное: свой Dropbox.
>> > Правда, в качестве хранилища по умолчанию - git.
>> > Интересная штука, но у меня пока слабое представление о том, что с ней
>> > возможно сделать, решит ли это мои задачи.
>>
>> Вообще, должен сказать, что существующие системы контроля версий с
>> задачами бэкапа довольно плохо совместимы. Поскольку по построению
>> хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
>> со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
>> небольшую выборку, а промежуточные состояния периодически удалять.
>>
> Тут не вполне верно. Гит же достаточно гибкий. Есть git-binary (как-то
> так) для внешнего хранения бинарей: они тоже могли реализовать своё
> бинарное хранилище, как модуль гита.
Я поэтому довольно осторожно сказал "плохо", а не "несовместимы". По
поводу конкретно гита нагуглилось такое:
https://www.perforce.com/blog/storing-large-binary-files-in-git-repositories
По косому взгляду, для задач бэкапа одно другого хуже.
>> >> - NextCloud
>> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>> > почему называется "облаком", легко ли его интегрировать с той же Bacula
>> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>> > использовать в составе NAS.
>>
>> >> - SyncThing
>> > Сам уже нашёл.
>> > Хотелось бы о нём услышать отзывы использующих.
>> > По мне: весьма интересная штука.
>>
>> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>>
> По каким причинам?
> Тут бы неплохо прояснить разницу.
> Если из бэкапа требуется доставать отдельные файлы, то границу мне
> сложно провести.
Синхронизатор не отличает намеренное удаление или порчу от
ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
засинхронизироваться.
>> >> - rsync поддерживает использование ssh как транспорт, существуют так же
>> >> надстройки разные
>> >>
>> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
>> > придётся всё доделывать самостоятельно, а в той же Bacula большинство
>> > функций реализовано и отлажено.
>>
>> >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
>> >> абстрактно...
>> >>
>> > 1. Шифрование бэкапов.
>> > 2. Репликация в выбранное облако (например, dropbox).
>>
>> > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
>> > Т.к. раньше я ими не пользовался, ничего конкретного про
>> > репликацию/наличие API спросить не могу.
>>
>> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
>> сети", и "восстанавливать за разумное время" - выберите любые два из
>> трех.
> Первые два, но время именно "разумное", я же не говорю "быстро".
Я тоже говорю "разумное". Выберите любые два из трех.
>> Инкрементальный бэкап, который обеспечивает tar и основные
>> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> как у rsync, второе и третье ценой невозможности первого. Первое и
>> третье можно делать, гоняя каждый раз полный бэкап.
>>
> Вы не вполне верно поняли требование, либо я не точно выразился.
> Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
> (облако).
> Шифровать отдельно при хранении в NAS, не требуется.
Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
вообще-то, выбирать разные два из трех. Но, естественно, получатся
разные технологии бэкапа :)
>> В многолетней практике (man tar, там эта практика еще со времен бэкапов
>> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>> по временнЫм характеристикам) обычно устраивают комбинированное решение:
>> раз в некоторое время гонят полный бэкап, а между ними
>> инкрементальный. tar вот даже различает дифференциальный (разница с
>> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
>> ни был). Для разумного времени восстановления характерная частота
>> полного - раз в месяц, дифференциального - в неделю, инкрементального -
>> ежедневно. В результате получается дорого, но не невменяемо дорого.
>>
> Любопытно, на основе инструментов, которые тут советовали, возможно это
> построить не сильно напрягаясь?
Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
не позволяет, его нужно выкинуть и посмотреть на другой.
На глазок, при использовании собственно tar, gpg и любого способа
копирования такая конструкция собирается за неделю, включая написание
регламента. Но трафика будет изрядно.
>> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> при работе в архиве, но все же изрядная.
> Она мне, в принципе, требуется.
> В плане организации я пытаюсь сейчас всё постепенно рассортировать
> (сейчас закончил только с музыкой и видео, проекты в нормальном
> состоянии, книги и документы в процессе сортировки).
> Поэтому, что бэкапить, я могу сказать.
Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>> "Результатом автоматизации
>> бардака может быть только автоматизированный бардак." В нее, в
>> частности, входит периодическая тренировка восстановления из
>> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
>> получится восстановиться.
>>
> С проведением таких "учений" всё сложнее: как восстанавливать машину, на
> которой постоянно работаешь (в любом случае, восстановление - потеря
> времени)?
Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно
делаешь, либо у тебя очень невысокие шансы, что ты сможешь
восстановиться в случае проблем.
Вероятность того, что при первой попытке восстановления проблемы
возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
все же заметно больше нуля, и чем сложнее инфраструктура хранения
резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
аргумент в пользу решений на базе rsync, у которых на выходе такое же
дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
лучше, чтобы первые несколько тревог были учебными.
>> >> - git-annex - то, что и можно предположить: костыль над гитом.
>> > `Git's man page calls it "a stupid content tracker". With git-annex, git
>> > is instead "a stupid filename and metadata" tracker. The contents of
>> > annexed files are not stored in git, only the names of the files and
>> > some other metadata remain there.`
>>
>> > Насколько проще с этим будет работать, чем с Bacula?
>> > Насколько переносимо и отлажено?
>> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
>> > пока не ясно (к примеру, централизованного управления и интеграции в
>> > web-интерфейс там, пожалуй, нет).
>>
>> Не путаем бэкап с архивом. Для бэкапа не годится.
>>
> По каким причинам?
>> >> - SparkleShare - что-то весьма минималистичное
>> > Неслабо минималистичное: свой Dropbox.
>> > Правда, в качестве хранилища по умолчанию - git.
>> > Интересная штука, но у меня пока слабое представление о том, что с ней
>> > возможно сделать, решит ли это мои задачи.
>>
>> Вообще, должен сказать, что существующие системы контроля версий с
>> задачами бэкапа довольно плохо совместимы. Поскольку по построению
>> хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
>> со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
>> небольшую выборку, а промежуточные состояния периодически удалять.
>>
> Тут не вполне верно. Гит же достаточно гибкий. Есть git-binary (как-то
> так) для внешнего хранения бинарей: они тоже могли реализовать своё
> бинарное хранилище, как модуль гита.
поводу конкретно гита нагуглилось такое:
https://www.perforce.com/blog/storing-large-binary-files-in-git-repositories
По косому взгляду, для задач бэкапа одно другого хуже.
>> >> - NextCloud
>> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>> > почему называется "облаком", легко ли его интегрировать с той же Bacula
>> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>> > использовать в составе NAS.
>>
>> >> - SyncThing
>> > Сам уже нашёл.
>> > Хотелось бы о нём услышать отзывы использующих.
>> > По мне: весьма интересная штука.
>>
>> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>>
> По каким причинам?
> Тут бы неплохо прояснить разницу.
> Если из бэкапа требуется доставать отдельные файлы, то границу мне
> сложно провести.
ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
засинхронизироваться.
>> >> - rsync поддерживает использование ssh как транспорт, существуют так же
>> >> надстройки разные
>> >>
>> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
>> > придётся всё доделывать самостоятельно, а в той же Bacula большинство
>> > функций реализовано и отлажено.
>>
>> >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
>> >> абстрактно...
>> >>
>> > 1. Шифрование бэкапов.
>> > 2. Репликация в выбранное облако (например, dropbox).
>>
>> > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
>> > Т.к. раньше я ими не пользовался, ничего конкретного про
>> > репликацию/наличие API спросить не могу.
>>
>> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
>> сети", и "восстанавливать за разумное время" - выберите любые два из
>> трех.
> Первые два, но время именно "разумное", я же не говорю "быстро".
>> Инкрементальный бэкап, который обеспечивает tar и основные
>> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> как у rsync, второе и третье ценой невозможности первого. Первое и
>> третье можно делать, гоняя каждый раз полный бэкап.
>>
> Вы не вполне верно поняли требование, либо я не точно выразился.
> Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
> (облако).
> Шифровать отдельно при хранении в NAS, не требуется.
вообще-то, выбирать разные два из трех. Но, естественно, получатся
разные технологии бэкапа :)
>> В многолетней практике (man tar, там эта практика еще со времен бэкапов
>> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>> по временнЫм характеристикам) обычно устраивают комбинированное решение:
>> раз в некоторое время гонят полный бэкап, а между ними
>> инкрементальный. tar вот даже различает дифференциальный (разница с
>> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
>> ни был). Для разумного времени восстановления характерная частота
>> полного - раз в месяц, дифференциального - в неделю, инкрементального -
>> ежедневно. В результате получается дорого, но не невменяемо дорого.
>>
> Любопытно, на основе инструментов, которые тут советовали, возможно это
> построить не сильно напрягаясь?
не позволяет, его нужно выкинуть и посмотреть на другой.
На глазок, при использовании собственно tar, gpg и любого способа
копирования такая конструкция собирается за неделю, включая написание
регламента. Но трафика будет изрядно.
>> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> при работе в архиве, но все же изрядная.
> Она мне, в принципе, требуется.
> В плане организации я пытаюсь сейчас всё постепенно рассортировать
> (сейчас закончил только с музыкой и видео, проекты в нормальном
> состоянии, книги и документы в процессе сортировки).
> Поэтому, что бэкапить, я могу сказать.
проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>> "Результатом автоматизации
>> бардака может быть только автоматизированный бардак." В нее, в
>> частности, входит периодическая тренировка восстановления из
>> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
>> получится восстановиться.
>>
> С проведением таких "учений" всё сложнее: как восстанавливать машину, на
> которой постоянно работаешь (в любом случае, восстановление - потеря
> времени)?
делаешь, либо у тебя очень невысокие шансы, что ты сможешь
восстановиться в случае проблем.
Вероятность того, что при первой попытке восстановления проблемы
возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
все же заметно больше нуля, и чем сложнее инфраструктура хранения
резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
аргумент в пользу решений на базе rsync, у которых на выходе такое же
дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
лучше, чтобы первые несколько тревог были учебными.
Artem Chuprina
Feb 16, 2018, 5:00:02 PM2/16/18
to
artiom -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 21:54:34 +0300:
>> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> >>> выбранные пользовательские данные.
>> >>
>> >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
>> >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>> >> восстановления не разбираться если версии конфигурации в /etc остались
>> >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>> >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>> > Как минимум, две машины (плюс, ещё /opt).
>> > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>> > для Oracle Java на рабочей машине).
>> > /var ещё надо бэкапить. Но /usr для чего?
>>
>> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
>> чистый диск не получится. Придется ставить систему и накатывать
>> конфиги. И тут упс... система оказалась поновее, конфиги частично
>> несовместимы...
>>
> Это не столь серьёзная проблема в моём случае: как правило, система
> более ли менее новая.
Ключевые слова - "более или менее" :)
>> >> В общем, анализировать бэкапные решения надо начинать не с "где
>> >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
>> >> процедура восстановления". Причем в двух вариантах
>> >>
>> > Да, вообще явного анализа восстановления я не провёл.
>> > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
>> > данные, а не образ.
>> > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
>> > машин.
>>
>> Практика восстановления показывает, что если бэкапятся настройки
>> системы, то лучше бэкапить всю систему. Восстановление работоспособного
>> состояния получится на порядок быстрее. Пользовательские данные можно (и
>> часто полезно) бэкапить отдельно.
>>
> Хорошо, но зачем мне 50+ Гб того, что я и так получу?
> Мало того, не всегда мне нужно будет восстанавливать ту же самую
> систему: на том же железе и в точности с той же конфигурацией, плюс к
> этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
> Падение скорости восстановления здесь для меня терпимо.
Системы обычно падают в самый неподходящий момент :) И даже если ты
давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
прежнюю работоспособную конфигурацию, а потом уже обновлять.
>> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
>> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
>> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
>> машин и есть человек, который регулярно подкручивает эту конструкцию. С
>> квалификацией админа и наличием _регулярно_ времени на эту работу.
>>
> Насколько регулярно и насколько велик объём донастройки?
Мне пока не доводилось работать в таком месте, где работодатель считал
бы, что это ему по карману :)
Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
и набор пакетов привел меня к выводу, что потребуется специальный
бэкап-админ как минимум на полставки. Кончилось регламентом на базе
tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
виртуалки с виндой.
Ну, то есть, конторы, где эти или подобные технологии применялись, я
видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
раз - только потому, что у меня был еще и свой бэкап.
Со своих "велосипедных" бэкапов восстанавливаться несколько раз
приходилось. Однажды полностью, и несколько раз вытаскивать из прошлых
бэкапов пользовательские файлы.
>> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> >>> выбранные пользовательские данные.
>> >>
>> >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
>> >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>> >> восстановления не разбираться если версии конфигурации в /etc остались
>> >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>> >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>> > Как минимум, две машины (плюс, ещё /opt).
>> > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>> > для Oracle Java на рабочей машине).
>> > /var ещё надо бэкапить. Но /usr для чего?
>>
>> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
>> чистый диск не получится. Придется ставить систему и накатывать
>> конфиги. И тут упс... система оказалась поновее, конфиги частично
>> несовместимы...
>>
> Это не столь серьёзная проблема в моём случае: как правило, система
> более ли менее новая.
>> >> В общем, анализировать бэкапные решения надо начинать не с "где
>> >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
>> >> процедура восстановления". Причем в двух вариантах
>> >>
>> > Да, вообще явного анализа восстановления я не провёл.
>> > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
>> > данные, а не образ.
>> > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
>> > машин.
>>
>> Практика восстановления показывает, что если бэкапятся настройки
>> системы, то лучше бэкапить всю систему. Восстановление работоспособного
>> состояния получится на порядок быстрее. Пользовательские данные можно (и
>> часто полезно) бэкапить отдельно.
>>
> Хорошо, но зачем мне 50+ Гб того, что я и так получу?
> Мало того, не всегда мне нужно будет восстанавливать ту же самую
> систему: на том же железе и в точности с той же конфигурацией, плюс к
> этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
> Падение скорости восстановления здесь для меня терпимо.
давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
прежнюю работоспособную конфигурацию, а потом уже обновлять.
>> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
>> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
>> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
>> машин и есть человек, который регулярно подкручивает эту конструкцию. С
>> квалификацией админа и наличием _регулярно_ времени на эту работу.
>>
> Насколько регулярно и насколько велик объём донастройки?
бы, что это ему по карману :)
Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
и набор пакетов привел меня к выводу, что потребуется специальный
бэкап-админ как минимум на полставки. Кончилось регламентом на базе
tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
виртуалки с виндой.
Ну, то есть, конторы, где эти или подобные технологии применялись, я
видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
раз - только потому, что у меня был еще и свой бэкап.
Со своих "велосипедных" бэкапов восстанавливаться несколько раз
приходилось. Однажды полностью, и несколько раз вытаскивать из прошлых
бэкапов пользовательские файлы.
artiom
Feb 17, 2018, 2:40:02 AM2/17/18
to
17.02.2018 00:50, Artem Chuprina пишет:
> artiom -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 21:54:34 +0300:
>
> >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> >> >>> выбранные пользовательские данные.
> >> >>
> >> >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
> >> >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
> >> >> восстановления не разбираться если версии конфигурации в /etc остались
> >> >> от чуточку более старых пакетов, чем поставились из дистрибутива при
> >> >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
> >> > Как минимум, две машины (плюс, ещё /opt).
> >> > В /usr я руками ничего не правлю обычно (за крайне редким исключением
> >> > для Oracle Java на рабочей машине).
> >> > /var ещё надо бэкапить. Но /usr для чего?
> >>
> >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
> >> чистый диск не получится. Придется ставить систему и накатывать
> >> конфиги. И тут упс... система оказалась поновее, конфиги частично
> >> несовместимы...
> >>
> > Это не столь серьёзная проблема в моём случае: как правило, система
> > более ли менее новая.
>
> Ключевые слова - "более или менее" :)
Ok, система достаточно новая. Максимум - месяц без обновлений (это
>
> >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> >> >>> выбранные пользовательские данные.
> >> >>
> >> >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
> >> >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
> >> >> восстановления не разбираться если версии конфигурации в /etc остались
> >> >> от чуточку более старых пакетов, чем поставились из дистрибутива при
> >> >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
> >> > Как минимум, две машины (плюс, ещё /opt).
> >> > В /usr я руками ничего не правлю обычно (за крайне редким исключением
> >> > для Oracle Java на рабочей машине).
> >> > /var ещё надо бэкапить. Но /usr для чего?
> >>
> >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
> >> чистый диск не получится. Придется ставить систему и накатывать
> >> конфиги. И тут упс... система оказалась поновее, конфиги частично
> >> несовместимы...
> >>
> > Это не столь серьёзная проблема в моём случае: как правило, система
> > более ли менее новая.
>
> Ключевые слова - "более или менее" :)
означает, что она не включалась, потому вероятность выхода из строя
низка), и как правило, в таком случае я могу себе позволить затратить
время на её восстановление. Больше - крайне редкие случаи.
>
> >> >> В общем, анализировать бэкапные решения надо начинать не с "где
> >> >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
> >> >> процедура восстановления". Причем в двух вариантах
> >> >>
> >> > Да, вообще явного анализа восстановления я не провёл.
> >> > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
> >> > данные, а не образ.
> >> > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
> >> > машин.
> >>
> >> Практика восстановления показывает, что если бэкапятся настройки
> >> системы, то лучше бэкапить всю систему. Восстановление работоспособного
> >> состояния получится на порядок быстрее. Пользовательские данные можно (и
> >> часто полезно) бэкапить отдельно.
> >>
> > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
> > Мало того, не всегда мне нужно будет восстанавливать ту же самую
> > систему: на том же железе и в точности с той же конфигурацией, плюс к
> > этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
> > Падение скорости восстановления здесь для меня терпимо.
>
> Системы обычно падают в самый неподходящий момент :) И даже если ты
> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
> прежнюю работоспособную конфигурацию, а потом уже обновлять.
>
кем-то решённых).
Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру"
(пусть и маленькую).
Отсюда:
- Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го
года не переустанавливалась, редко выключалась, кроме последних лет, и
долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет
заботливо сохранена, и воспроизведётся при каждом полном восстановлении.
- В этой старой системе я хочу многое переделать, например дисковую
организацию, что потребует переустановки при сохранении большинства
конфигов.
Как решаются эти проблемы?
Надо ли мне, в таком случае, делать полный бэкап?
> >> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
> >> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
> >> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
> >> машин и есть человек, который регулярно подкручивает эту конструкцию. С
> >> квалификацией админа и наличием _регулярно_ времени на эту работу.
> >>
> > Насколько регулярно и насколько велик объём донастройки?
>
> Мне пока не доводилось работать в таком месте, где работодатель считал
> бы, что это ему по карману :)
>
> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
> и набор пакетов привел меня к выводу, что потребуется специальный
> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
> виртуалки с виндой.
>
http://www.urbackup.org/
https://time404.ru/1776/
> Ну, то есть, конторы, где эти или подобные технологии применялись, я
> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
> раз - только потому, что у меня был еще и свой бэкап.
>
Почему не было успешно её применение?
Возможно ли, что это просто было неправильное использование?
> Со своих "велосипедных" бэкапов восстанавливаться несколько раз
> приходилось. Однажды полностью, и несколько раз вытаскивать из прошлых
> бэкапов пользовательские файлы.
>
artiom
Feb 17, 2018, 3:20:02 AM2/17/18
to
17.02.2018 00:35, Artem Chuprina пишет:
> artiom -> debian-...@lists.debian.org @ Fri, 16 Feb 2018 22:25:22 +0300:
>
> >> >> - git-annex - то, что и можно предположить: костыль над гитом.
> >> > `Git's man page calls it "a stupid content tracker". With git-annex, git
> >> > is instead "a stupid filename and metadata" tracker. The contents of
> >> > annexed files are not stored in git, only the names of the files and
> >> > some other metadata remain there.`
> >>
> >> > Насколько проще с этим будет работать, чем с Bacula?
> >> > Насколько переносимо и отлажено?
> >> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
> >> > пока не ясно (к примеру, централизованного управления и интеграции в
> >> > web-интерфейс там, пожалуй, нет).
> >>
> >> Не путаем бэкап с архивом. Для бэкапа не годится.
> >>
> > По каким причинам?
>
> Требует архивной дисциплины. Я использовал его, ага.
>
git-annex?
>
> >> >> - git-annex - то, что и можно предположить: костыль над гитом.
> >> > `Git's man page calls it "a stupid content tracker". With git-annex, git
> >> > is instead "a stupid filename and metadata" tracker. The contents of
> >> > annexed files are not stored in git, only the names of the files and
> >> > some other metadata remain there.`
> >>
> >> > Насколько проще с этим будет работать, чем с Bacula?
> >> > Насколько переносимо и отлажено?
> >> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
> >> > пока не ясно (к примеру, централизованного управления и интеграции в
> >> > web-интерфейс там, пожалуй, нет).
> >>
> >> Не путаем бэкап с архивом. Для бэкапа не годится.
> >>
> > По каким причинам?
>
> Требует архивной дисциплины. Я использовал его, ага.
>
> >> >> - SparkleShare - что-то весьма минималистичное
> >> > Неслабо минималистичное: свой Dropbox.
> >> > Правда, в качестве хранилища по умолчанию - git.
> >> > Интересная штука, но у меня пока слабое представление о том, что с ней
> >> > возможно сделать, решит ли это мои задачи.
> >>
> >> Вообще, должен сказать, что существующие системы контроля версий с
> >> задачами бэкапа довольно плохо совместимы. Поскольку по построению
> >> хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
> >> со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
> >> небольшую выборку, а промежуточные состояния периодически удалять.
> >>
> > Тут не вполне верно. Гит же достаточно гибкий. Есть git-binary (как-то
> > так) для внешнего хранения бинарей: они тоже могли реализовать своё
> > бинарное хранилище, как модуль гита.
>
> Я поэтому довольно осторожно сказал "плохо", а не "несовместимы". По
> поводу конкретно гита нагуглилось такое:
>
> https://www.perforce.com/blog/storing-large-binary-files-in-git-repositories
>
> По косому взгляду, для задач бэкапа одно другого хуже.
>
И нужны они всё-таки для задач разработки.
Бэкап тут за уши притянут, не спорю.
> >> >> - NextCloud
> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
> >> > почему называется "облаком", легко ли его интегрировать с той же Bacula
> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
> >> > использовать в составе NAS.
> >>
> >> >> - SyncThing
> >> > Сам уже нашёл.
> >> > Хотелось бы о нём услышать отзывы использующих.
> >> > По мне: весьма интересная штука.
> >>
> >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
> >>
> > По каким причинам?
> > Тут бы неплохо прояснить разницу.
> > Если из бэкапа требуется доставать отдельные файлы, то границу мне
> > сложно провести.
>
> Синхронизатор не отличает намеренное удаление или порчу от
> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
> засинхронизироваться.
>
Или тоже не отличает, но это компенсируется историей бэкапов?
> >> >> - rsync поддерживает использование ssh как транспорт, существуют так же
> >> >> надстройки разные
> >> >>
> >> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
> >> > придётся всё доделывать самостоятельно, а в той же Bacula большинство
> >> > функций реализовано и отлажено.
> >>
> >> >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
> >> >> абстрактно...
> >> >>
> >> > 1. Шифрование бэкапов.
> >> > 2. Репликация в выбранное облако (например, dropbox).
> >>
> >> > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
> >> > Т.к. раньше я ими не пользовался, ничего конкретного про
> >> > репликацию/наличие API спросить не могу.
> >>
> >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
> >> сети", и "восстанавливать за разумное время" - выберите любые два из
> >> трех.
> > Первые два, но время именно "разумное", я же не говорю "быстро".
>
> Я тоже говорю "разумное". Выберите любые два из трех.
>
бэкапа (места должно хватить, плюс снэпшоты ZFS).
> >> Инкрементальный бэкап, который обеспечивает tar и основные
> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
> >> как у rsync, второе и третье ценой невозможности первого. Первое и
> >> третье можно делать, гоняя каждый раз полный бэкап.
> >>
> > Вы не вполне верно поняли требование, либо я не точно выразился.
> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
> > (облако).
> > Шифровать отдельно при хранении в NAS, не требуется.
>
> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
> вообще-то, выбирать разные два из трех. Но, естественно, получатся
> разные технологии бэкапа :)
>
> >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
> >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
> >> раз в некоторое время гонят полный бэкап, а между ними
> >> инкрементальный. tar вот даже различает дифференциальный (разница с
> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
> >> ни был). Для разумного времени восстановления характерная частота
> >> полного - раз в месяц, дифференциального - в неделю, инкрементального -
> >> ежедневно. В результате получается дорого, но не невменяемо дорого.
> >>
> > Любопытно, на основе инструментов, которые тут советовали, возможно это
> > построить не сильно напрягаясь?
>
> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
> не позволяет, его нужно выкинуть и посмотреть на другой.
>
Пока не вполне понятно, что из этого выкинуть.
Кроме Bacula, но тут хвалят её форки.
> На глазок, при использовании собственно tar, gpg и любого способа
> копирования такая конструкция собирается за неделю, включая написание
> регламента. Но трафика будет изрядно.
>
> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
> >> при работе в архиве, но все же изрядная.
> > Она мне, в принципе, требуется.
> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
> > (сейчас закончил только с музыкой и видео, проекты в нормальном
> > состоянии, книги и документы в процессе сортировки).
> > Поэтому, что бэкапить, я могу сказать.
>
> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>
Если делать на серьёзном уровне, конечно полезно.
В принципе, это в любом случае полезно, так что пока ещё NAS не
завершён, в рамках этого проекта возможно и системой резервного
копирования более серьёзно заняться.
> >> "Результатом автоматизации
> >> бардака может быть только автоматизированный бардак." В нее, в
> >> частности, входит периодическая тренировка восстановления из
> >> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
> >> получится восстановиться.
> >>
> > С проведением таких "учений" всё сложнее: как восстанавливать машину, на
> > которой постоянно работаешь (в любом случае, восстановление - потеря
> > времени)?
>
> Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно
> делаешь, либо у тебя очень невысокие шансы, что ты сможешь
> восстановиться в случае проблем.
>
> Вероятность того, что при первой попытке восстановления проблемы
> возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
> все же заметно больше нуля, и чем сложнее инфраструктура хранения
> резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
> аргумент в пользу решений на базе rsync, у которых на выходе такое же
> дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
> лучше, чтобы первые несколько тревог были учебными.
>
инкрементальный бэкап?
Касательно проверок: как это делается?
На практике, там где это было, как проводится такая проверка в
существующей инфраструктуре?
artiom
Feb 17, 2018, 4:00:02 AM2/17/18
to
> >> >> - rsync поддерживает использование ssh как транспорт, существуют так же
> >> >> надстройки разные
> >> >>
> >> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
> >> > придётся всё доделывать самостоятельно, а в той же Bacula большинство
> >> > функций реализовано и отлажено.
> >>
> >> >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
> >> >> абстрактно...
> >> >>
> >> > 1. Шифрование бэкапов.
> >> > 2. Репликация в выбранное облако (например, dropbox).
> >>
> >> > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
> >> > Т.к. раньше я ими не пользовался, ничего конкретного про
> >> > репликацию/наличие API спросить не могу.
> >>
> >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
> >> сети", и "восстанавливать за разумное время" - выберите любые два из
> >> трех.
> > Первые два, но время именно "разумное", я же не говорю "быстро".
>
> Я тоже говорю "разумное". Выберите любые два из трех.
>
В процессе изучения вопроса я обнаружил, что есть такая технология, как
> >> >> надстройки разные
> >> >>
> >> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
> >> > придётся всё доделывать самостоятельно, а в той же Bacula большинство
> >> > функций реализовано и отлажено.
> >>
> >> >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
> >> >> абстрактно...
> >> >>
> >> > 1. Шифрование бэкапов.
> >> > 2. Репликация в выбранное облако (например, dropbox).
> >>
> >> > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
> >> > Т.к. раньше я ими не пользовался, ничего конкретного про
> >> > репликацию/наличие API спросить не могу.
> >>
> >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
> >> сети", и "восстанавливать за разумное время" - выберите любые два из
> >> трех.
> > Первые два, но время именно "разумное", я же не говорю "быстро".
>
> Я тоже говорю "разумное". Выберите любые два из трех.
>
дедупликация на клиенте.
И вообще, как ни странно, в случае с файлопомойками, дедап позволяет
экономить до 98% дискового пространства.
В моём случае, даже если 20% я сэкономлю - уже неплохо, но только не
средствами ZFS.
Коротаев Руслан
Feb 17, 2018, 5:40:03 AM2/17/18
to
В сообщении от [Пт 2018-02-16 20:52 +0300]
artiom <arti...@yandex.ru> пишет:
> Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки?
Nextcloud? Да, конечно. Он всё-в-одном, не нужно носить с собой ноутбук,
у меня там почта, RSS-читалка, музыкальный плеер, контакты, календарь.
Для меня это мобильное рабочее место, нужен только браузер
(двухфакторная аутентификация тоже есть).
Плюс приватность, когда вы загружаете файлы в публичный сервис, то они
уже не только ваши, но и чьи-то ещё. Но в Nextcloud есть плагин «внешние
хранилища», можно дополнительно подключить Dropbox, Amazon S3 …
> Вопрос по протоколам в том, нужны ли все эти FTPS и прочие в "облаке",
> когда NAS может предоставить их отдельно (подняв FTP сервер, например)?
Если у вас NAS специально для бекапов, то наверное нет, всё зависит от
контекста, здесь сколько людей столько и мнений. Для меня NAS это
хлопотно (нужно думать какое железо под него купить, RAID или ZFS, а
вдруг не хватит места и всё такое, да ещё вентилятор шумит), с облаками
проще, больше вариантов использования [1].
Кстати, в этом треде возникла идея разделять синхронизацию и бекап.
Бекап в отличии от синхронизации имеет дедупликацию, снапшоты,
шифрование. Я нашел такую прогу — restic [2], он всё это может плюс
сразу отправляет в облако.
[1]: https://habrahabr.ru/post/348542/
[2]: https://restic.net/
artiom <arti...@yandex.ru> пишет:
> Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки?
у меня там почта, RSS-читалка, музыкальный плеер, контакты, календарь.
Для меня это мобильное рабочее место, нужен только браузер
(двухфакторная аутентификация тоже есть).
Плюс приватность, когда вы загружаете файлы в публичный сервис, то они
уже не только ваши, но и чьи-то ещё. Но в Nextcloud есть плагин «внешние
хранилища», можно дополнительно подключить Dropbox, Amazon S3 …
> Вопрос по протоколам в том, нужны ли все эти FTPS и прочие в "облаке",
> когда NAS может предоставить их отдельно (подняв FTP сервер, например)?
контекста, здесь сколько людей столько и мнений. Для меня NAS это
хлопотно (нужно думать какое железо под него купить, RAID или ZFS, а
вдруг не хватит места и всё такое, да ещё вентилятор шумит), с облаками
проще, больше вариантов использования [1].
Кстати, в этом треде возникла идея разделять синхронизацию и бекап.
Бекап в отличии от синхронизации имеет дедупликацию, снапшоты,
шифрование. Я нашел такую прогу — restic [2], он всё это может плюс
сразу отправляет в облако.
[1]: https://habrahabr.ru/post/348542/
[2]: https://restic.net/
Artem Chuprina
Feb 17, 2018, 11:30:03 AM2/17/18
to
artiom -> debian-...@lists.debian.org @ Sat, 17 Feb 2018 11:56:37 +0300:
Это, гм, новость. По моим представлениям, дедупликация на файлопомойке
(где вообще-то каждый файл в среднем чуть более чем в одном экземпляре)
дает от силы процентов 10, если она пофайловая, и процентов 20, если
поблочная. А более вероятно - 3 и 5% соответственно. 98% - это надо
чтобы каждый файл (или блок) хранился в среднем в 50 экземплярах. Я могу
себе такое представить на хранилище, откуда работают сотни виртуальных
машин, но на файлопомойке?
Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
15). Но не в 50.
(где вообще-то каждый файл в среднем чуть более чем в одном экземпляре)
дает от силы процентов 10, если она пофайловая, и процентов 20, если
поблочная. А более вероятно - 3 и 5% соответственно. 98% - это надо
чтобы каждый файл (или блок) хранился в среднем в 50 экземплярах. Я могу
себе такое представить на хранилище, откуда работают сотни виртуальных
машин, но на файлопомойке?
Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
15). Но не в 50.
Artem Chuprina
Feb 17, 2018, 11:50:02 AM2/17/18
to
artiom -> debian-...@lists.debian.org @ Sat, 17 Feb 2018 11:16:16 +0300:
>> >> >> - git-annex - то, что и можно предположить: костыль над гитом.
>> >> > `Git's man page calls it "a stupid content tracker". With git-annex, git
>> >> > is instead "a stupid filename and metadata" tracker. The contents of
>> >> > annexed files are not stored in git, only the names of the files and
>> >> > some other metadata remain there.`
>> >>
>> >> > Насколько проще с этим будет работать, чем с Bacula?
>> >> > Насколько переносимо и отлажено?
>> >> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
>> >> > пока не ясно (к примеру, централизованного управления и интеграции в
>> >> > web-интерфейс там, пожалуй, нет).
>> >>
>> >> Не путаем бэкап с архивом. Для бэкапа не годится.
>> >>
>> > По каким причинам?
>>
>> Требует архивной дисциплины. Я использовал его, ага.
>>
> git-annex?
Да. Архивные, т.е. _не изменяющиеся_, здоровенные бинарники, с
отслеживанием, где и сколько их копий, и комментированием, где что за
хрень. Он придуман для этой задачи, и ее выполняет хорошо.
Потом как-то продолбал дисциплину архивной работы, и теперь уже поди
найди хотя бы один репозиторий, где вся эта информация...
>> >> >> - NextCloud
>> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>> >> > почему называется "облаком", легко ли его интегрировать с той же Bacula
>> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>> >> > использовать в составе NAS.
>> >>
>> >> >> - SyncThing
>> >> > Сам уже нашёл.
>> >> > Хотелось бы о нём услышать отзывы использующих.
>> >> > По мне: весьма интересная штука.
>> >>
>> >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>> >>
>> > По каким причинам?
>> > Тут бы неплохо прояснить разницу.
>> > Если из бэкапа требуется доставать отдельные файлы, то границу мне
>> > сложно провести.
>>
>> Синхронизатор не отличает намеренное удаление или порчу от
>> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
>> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
>> засинхронизироваться.
>>
> Как отличает система резервного копирования?
> Или тоже не отличает, но это компенсируется историей бэкапов?
Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
удаляется целиком, либо (если ему повезло оказаться, например, годичным)
хранится "вечно".
>> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >>
>> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> > (облако).
>> > Шифровать отдельно при хранении в NAS, не требуется.
>>
>> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> разные технологии бэкапа :)
>>
> Да, конечно, так и планировалось изначально.
Минус простота настройки.
>> >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
>> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>> >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
>> >> раз в некоторое время гонят полный бэкап, а между ними
>> >> инкрементальный. tar вот даже различает дифференциальный (разница с
>> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
>> >> ни был). Для разумного времени восстановления характерная частота
>> >> полного - раз в месяц, дифференциального - в неделю, инкрементального -
>> >> ежедневно. В результате получается дорого, но не невменяемо дорого.
>> >>
>> > Любопытно, на основе инструментов, которые тут советовали, возможно это
>> > построить не сильно напрягаясь?
>>
>> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
>> не позволяет, его нужно выкинуть и посмотреть на другой.
>>
> Согласен.
> Пока не вполне понятно, что из этого выкинуть.
> Кроме Bacula, но тут хвалят её форки.
>> На глазок, при использовании собственно tar, gpg и любого способа
>> копирования такая конструкция собирается за неделю, включая написание
>> регламента. Но трафика будет изрядно.
>>
> И не вполне портируемо.
Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на
винде не будут забэкаплены открытые в данный момент файлы.
>> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> >> при работе в архиве, но все же изрядная.
>> > Она мне, в принципе, требуется.
>> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
>> > (сейчас закончил только с музыкой и видео, проекты в нормальном
>> > состоянии, книги и документы в процессе сортировки).
>> > Поэтому, что бэкапить, я могу сказать.
>>
>> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
>> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>>
> Ну ok, политика и регламент бэкапа?
> Если делать на серьёзном уровне, конечно полезно.
> В принципе, это в любом случае полезно, так что пока ещё NAS не
> завершён, в рамках этого проекта возможно и системой резервного
> копирования более серьёзно заняться.
Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем,
чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
касающейся его части.
>> >> "Результатом автоматизации
>> >> бардака может быть только автоматизированный бардак." В нее, в
>> >> частности, входит периодическая тренировка восстановления из
>> >> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
>> >> получится восстановиться.
>> >>
>> > С проведением таких "учений" всё сложнее: как восстанавливать машину, на
>> > которой постоянно работаешь (в любом случае, восстановление - потеря
>> > времени)?
>>
>> Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно
>> делаешь, либо у тебя очень невысокие шансы, что ты сможешь
>> восстановиться в случае проблем.
>>
>> Вероятность того, что при первой попытке восстановления проблемы
>> возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
>> все же заметно больше нуля, и чем сложнее инфраструктура хранения
>> резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
>> аргумент в пользу решений на базе rsync, у которых на выходе такое же
>> дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
>> лучше, чтобы первые несколько тревог были учебными.
>>
> Хорошо, тогда касательно rsync: как делать дифференциальный и
> инкрементальный бэкап?
У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап,
и потом rsync -a --delete в будущий_бэкап.
Если бэкапится юниксовая машина, то вся конструкция без особых
сложностей скриптуется с сервера, который и следит за расписанием. С
виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
-al" и по расписанию пинал по почте владельца машины. А часть rsync
запускает уже владелец машины.
> Касательно проверок: как это делается?
> На практике, там где это было, как проводится такая проверка в
> существующей инфраструктуре?
Тупо и цинично. Берется специальная тренировочная машина, типа с пустым
диском (обычно виртуалка, но по возможности иногда и на железе стоит
прогнать), и на нее выполняется регламент восстановления. Если не
сработал - все бросаем, чиним, корректируем регламент.
Если речь идет о восстановлении пользовательских данных, а не всей
системы, то машина берется не пустая, а с установленной ОС. В этом
случае регламент восстановления должен включать установку необходимого
софта поверх базовой установки ОС (буде он нужен), если он еще не
установлен. Это тоже надо проверять, а то разное может получиться.
>> >> >> - git-annex - то, что и можно предположить: костыль над гитом.
>> >> > `Git's man page calls it "a stupid content tracker". With git-annex, git
>> >> > is instead "a stupid filename and metadata" tracker. The contents of
>> >> > annexed files are not stored in git, only the names of the files and
>> >> > some other metadata remain there.`
>> >>
>> >> > Насколько проще с этим будет работать, чем с Bacula?
>> >> > Насколько переносимо и отлажено?
>> >> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
>> >> > пока не ясно (к примеру, централизованного управления и интеграции в
>> >> > web-интерфейс там, пожалуй, нет).
>> >>
>> >> Не путаем бэкап с архивом. Для бэкапа не годится.
>> >>
>> > По каким причинам?
>>
>> Требует архивной дисциплины. Я использовал его, ага.
>>
> git-annex?
отслеживанием, где и сколько их копий, и комментированием, где что за
хрень. Он придуман для этой задачи, и ее выполняет хорошо.
Потом как-то продолбал дисциплину архивной работы, и теперь уже поди
найди хотя бы один репозиторий, где вся эта информация...
>> >> >> - NextCloud
>> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>> >> > почему называется "облаком", легко ли его интегрировать с той же Bacula
>> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>> >> > использовать в составе NAS.
>> >>
>> >> >> - SyncThing
>> >> > Сам уже нашёл.
>> >> > Хотелось бы о нём услышать отзывы использующих.
>> >> > По мне: весьма интересная штука.
>> >>
>> >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>> >>
>> > По каким причинам?
>> > Тут бы неплохо прояснить разницу.
>> > Если из бэкапа требуется доставать отдельные файлы, то границу мне
>> > сложно провести.
>>
>> Синхронизатор не отличает намеренное удаление или порчу от
>> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
>> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
>> засинхронизироваться.
>>
> Как отличает система резервного копирования?
> Или тоже не отличает, но это компенсируется историей бэкапов?
удаляется целиком, либо (если ему повезло оказаться, например, годичным)
хранится "вечно".
>> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >>
>> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> > (облако).
>> > Шифровать отдельно при хранении в NAS, не требуется.
>>
>> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> разные технологии бэкапа :)
>>
> Да, конечно, так и планировалось изначально.
>> >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
>> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>> >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
>> >> раз в некоторое время гонят полный бэкап, а между ними
>> >> инкрементальный. tar вот даже различает дифференциальный (разница с
>> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
>> >> ни был). Для разумного времени восстановления характерная частота
>> >> полного - раз в месяц, дифференциального - в неделю, инкрементального -
>> >> ежедневно. В результате получается дорого, но не невменяемо дорого.
>> >>
>> > Любопытно, на основе инструментов, которые тут советовали, возможно это
>> > построить не сильно напрягаясь?
>>
>> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
>> не позволяет, его нужно выкинуть и посмотреть на другой.
>>
> Согласен.
> Пока не вполне понятно, что из этого выкинуть.
> Кроме Bacula, но тут хвалят её форки.
>> На глазок, при использовании собственно tar, gpg и любого способа
>> копирования такая конструкция собирается за неделю, включая написание
>> регламента. Но трафика будет изрядно.
>>
> И не вполне портируемо.
винде не будут забэкаплены открытые в данный момент файлы.
>> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> >> при работе в архиве, но все же изрядная.
>> > Она мне, в принципе, требуется.
>> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
>> > (сейчас закончил только с музыкой и видео, проекты в нормальном
>> > состоянии, книги и документы в процессе сортировки).
>> > Поэтому, что бэкапить, я могу сказать.
>>
>> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
>> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>>
> Ну ok, политика и регламент бэкапа?
> Если делать на серьёзном уровне, конечно полезно.
> В принципе, это в любом случае полезно, так что пока ещё NAS не
> завершён, в рамках этого проекта возможно и системой резервного
> копирования более серьёзно заняться.
чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
касающейся его части.
>> >> "Результатом автоматизации
>> >> бардака может быть только автоматизированный бардак." В нее, в
>> >> частности, входит периодическая тренировка восстановления из
>> >> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
>> >> получится восстановиться.
>> >>
>> > С проведением таких "учений" всё сложнее: как восстанавливать машину, на
>> > которой постоянно работаешь (в любом случае, восстановление - потеря
>> > времени)?
>>
>> Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно
>> делаешь, либо у тебя очень невысокие шансы, что ты сможешь
>> восстановиться в случае проблем.
>>
>> Вероятность того, что при первой попытке восстановления проблемы
>> возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
>> все же заметно больше нуля, и чем сложнее инфраструктура хранения
>> резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
>> аргумент в пользу решений на базе rsync, у которых на выходе такое же
>> дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
>> лучше, чтобы первые несколько тревог были учебными.
>>
> Хорошо, тогда касательно rsync: как делать дифференциальный и
> инкрементальный бэкап?
и потом rsync -a --delete в будущий_бэкап.
Если бэкапится юниксовая машина, то вся конструкция без особых
сложностей скриптуется с сервера, который и следит за расписанием. С
виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
-al" и по расписанию пинал по почте владельца машины. А часть rsync
запускает уже владелец машины.
> Касательно проверок: как это делается?
> На практике, там где это было, как проводится такая проверка в
> существующей инфраструктуре?
диском (обычно виртуалка, но по возможности иногда и на железе стоит
прогнать), и на нее выполняется регламент восстановления. Если не
сработал - все бросаем, чиним, корректируем регламент.
Если речь идет о восстановлении пользовательских данных, а не всей
системы, то машина берется не пустая, а с установленной ОС. В этом
случае регламент восстановления должен включать установку необходимого
софта поверх базовой установки ОС (буде он нужен), если он еще не
установлен. Это тоже надо проверять, а то разное может получиться.
Artem Chuprina
Feb 17, 2018, 12:10:02 PM2/17/18
to
artiom -> debian-...@lists.debian.org @ Sat, 17 Feb 2018 10:39:21 +0300:
>> >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> >> >>> выбранные пользовательские данные.
>> >> >>
>> >> >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
>> >> >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>> >> >> восстановления не разбираться если версии конфигурации в /etc остались
>> >> >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>> >> >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>> >> > Как минимум, две машины (плюс, ещё /opt).
>> >> > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>> >> > для Oracle Java на рабочей машине).
>> >> > /var ещё надо бэкапить. Но /usr для чего?
>> >>
>> >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
>> >> чистый диск не получится. Придется ставить систему и накатывать
>> >> конфиги. И тут упс... система оказалась поновее, конфиги частично
>> >> несовместимы...
>> >>
>> > Это не столь серьёзная проблема в моём случае: как правило, система
>> > более ли менее новая.
>>
>> Ключевые слова - "более или менее" :)
> Ok, система достаточно новая. Максимум - месяц без обновлений (это
> означает, что она не включалась, потому вероятность выхода из строя
> низка), и как правило, в таком случае я могу себе позволить затратить
> время на её восстановление. Больше - крайне редкие случаи.
Бэкап, с которого восстанавливаемся, может оказаться не офигительно
свежим. Потом, легко забыть забэкапить что-нибудь важное из
/usr/local...
Не "есть риск", а "есть гарантия". Однако, в такой ситуации взять только
конфиги из полного бэкапа можно. А вот взять полную систему, чтобы
быстро восстановиться, если есть бэкап только конфигов, не получится.
Ну и думай, что дороже: дополнительное дисковое пространство для
хранения бэкапа системы, или твои время и нервы на более сложную
процедуру восстановления.
> - В этой старой системе я хочу многое переделать, например дисковую
> организацию, что потребует переустановки при сохранении большинства
> конфигов.
Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
перегенерировал initrd из чрута до первой перезагрузки, если в разметке
добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
>> >> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
>> >> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
>> >> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
>> >> машин и есть человек, который регулярно подкручивает эту конструкцию. С
>> >> квалификацией админа и наличием _регулярно_ времени на эту работу.
>> >>
>> > Насколько регулярно и насколько велик объём донастройки?
>>
>> Мне пока не доводилось работать в таком месте, где работодатель считал
>> бы, что это ему по карману :)
>>
> Если я делаю для себя, читается, как: "Ты не будешь этим заниматься"?
Скорее всего, да. У тебя же есть и другие занятия, а ты у себя один. И
кушать хочешь три раза в день, вероятно.
>> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
>> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
>> и набор пакетов привел меня к выводу, что потребуется специальный
>> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
>> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
>> виртуалки с виндой.
>>
> А форки, которые здесь рекламируют?
> http://www.urbackup.org/
> https://time404.ru/1776/
А можно я не буду на них смотреть? Но по идее, если форк, тем более
более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд
ли система с тех пор стала сильно проще...
>> Ну, то есть, конторы, где эти или подобные технологии применялись, я
>> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
>> раз - только потому, что у меня был еще и свой бэкап.
>>
> Но ведь система специально заточена под бэкап, долго живёт и развивается.
> Почему не было успешно её применение?
> Возможно ли, что это просто было неправильное использование?
Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
>> Со своих "велосипедных" бэкапов восстанавливаться несколько раз
>> приходилось. Однажды полностью, и несколько раз вытаскивать из прошлых
>> бэкапов пользовательские файлы.
>>
> tar?
Больше rsync, но и из tar тоже приходилось. Целиком накатывал из tar.
>> >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> >> >>> выбранные пользовательские данные.
>> >> >>
>> >> >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
>> >> >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>> >> >> восстановления не разбираться если версии конфигурации в /etc остались
>> >> >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>> >> >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>> >> > Как минимум, две машины (плюс, ещё /opt).
>> >> > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>> >> > для Oracle Java на рабочей машине).
>> >> > /var ещё надо бэкапить. Но /usr для чего?
>> >>
>> >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
>> >> чистый диск не получится. Придется ставить систему и накатывать
>> >> конфиги. И тут упс... система оказалась поновее, конфиги частично
>> >> несовместимы...
>> >>
>> > Это не столь серьёзная проблема в моём случае: как правило, система
>> > более ли менее новая.
>>
>> Ключевые слова - "более или менее" :)
> Ok, система достаточно новая. Максимум - месяц без обновлений (это
> означает, что она не включалась, потому вероятность выхода из строя
> низка), и как правило, в таком случае я могу себе позволить затратить
> время на её восстановление. Больше - крайне редкие случаи.
свежим. Потом, легко забыть забэкапить что-нибудь важное из
/usr/local...
конфиги из полного бэкапа можно. А вот взять полную систему, чтобы
быстро восстановиться, если есть бэкап только конфигов, не получится.
Ну и думай, что дороже: дополнительное дисковое пространство для
хранения бэкапа системы, или твои время и нервы на более сложную
процедуру восстановления.
> - В этой старой системе я хочу многое переделать, например дисковую
> организацию, что потребует переустановки при сохранении большинства
> конфигов.
поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
перегенерировал initrd из чрута до первой перезагрузки, если в разметке
добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
>> >> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
>> >> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
>> >> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
>> >> машин и есть человек, который регулярно подкручивает эту конструкцию. С
>> >> квалификацией админа и наличием _регулярно_ времени на эту работу.
>> >>
>> > Насколько регулярно и насколько велик объём донастройки?
>>
>> Мне пока не доводилось работать в таком месте, где работодатель считал
>> бы, что это ему по карману :)
>>
> Если я делаю для себя, читается, как: "Ты не будешь этим заниматься"?
кушать хочешь три раза в день, вероятно.
>> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
>> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
>> и набор пакетов привел меня к выводу, что потребуется специальный
>> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
>> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
>> виртуалки с виндой.
>>
> А форки, которые здесь рекламируют?
> http://www.urbackup.org/
> https://time404.ru/1776/
более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд
ли система с тех пор стала сильно проще...
>> Ну, то есть, конторы, где эти или подобные технологии применялись, я
>> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
>> раз - только потому, что у меня был еще и свой бэкап.
>>
> Но ведь система специально заточена под бэкап, долго живёт и развивается.
> Почему не было успешно её применение?
> Возможно ли, что это просто было неправильное использование?
>> Со своих "велосипедных" бэкапов восстанавливаться несколько раз
>> приходилось. Однажды полностью, и несколько раз вытаскивать из прошлых
>> бэкапов пользовательские файлы.
>>
> tar?
artiom
Feb 17, 2018, 3:30:03 PM2/17/18
to
17.02.2018 13:29, Коротаев Руслан пишет:
> В сообщении от [Пт 2018-02-16 20:52 +0300]
> artiom <arti...@yandex.ru> пишет:
>
>> Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки?
>
> Nextcloud? Да, конечно. Он всё-в-одном, не нужно носить с собой ноутбук,
> у меня там почта, RSS-читалка, музыкальный плеер, контакты, календарь.
> Для меня это мобильное рабочее место, нужен только браузер
> (двухфакторная аутентификация тоже есть).
>
А вот про плеер возможно подробнее?
> artiom <arti...@yandex.ru> пишет:
>
>> Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки?
>
> Nextcloud? Да, конечно. Он всё-в-одном, не нужно носить с собой ноутбук,
> у меня там почта, RSS-читалка, музыкальный плеер, контакты, календарь.
> Для меня это мобильное рабочее место, нужен только браузер
> (двухфакторная аутентификация тоже есть).
>
Я mpd хочу впилить.
> Плюс приватность, когда вы загружаете файлы в публичный сервис, то они
> уже не только ваши, но и чьи-то ещё. Но в Nextcloud есть плагин «внешние
> хранилища», можно дополнительно подключить Dropbox, Amazon S3 …
>
исключительно для хранения зашифрованного бэкапа.
>> Вопрос по протоколам в том, нужны ли все эти FTPS и прочие в "облаке",
>> когда NAS может предоставить их отдельно (подняв FTP сервер, например)?
>
> Если у вас NAS специально для бекапов, то наверное нет, всё зависит от
> контекста, здесь сколько людей столько и мнений. Для меня NAS это
> хлопотно (нужно думать какое железо под него купить, RAID или ZFS, а
> вдруг не хватит места и всё такое, да ещё вентилятор шумит), с облаками
> проще, больше вариантов использования [1].
>
выбирать долго и ZFS, тут не о чем думать.
Три основные задачи:
- Git.
- Бэкапы.
- Точка синхронизации.
Дополнительно (железо там мощное, пусть работает):
- Закачки.
- DLNA.
- Облако добавилось.
- Возможно, Mumble поставлю.
> Кстати, в этом треде возникла идея разделять синхронизацию и бекап.
> Бекап в отличии от синхронизации имеет дедупликацию, снапшоты,
> шифрование. Я нашел такую прогу — restic [2], он всё это может плюс
> сразу отправляет в облако.
>
> [1]: https://habrahabr.ru/post/348542/
> [2]: https://restic.net/
>
ней не слышал. С ней есть какие-то проблемы?
Почитал про Minio. Имеет ли смысл? Мне кажется, что в моём случае
NextCloud будет лучше?
Коротаев Руслан
Feb 18, 2018, 4:20:02 AM2/18/18
to
В сообщении от [Сб 2018-02-17 23:29 +0300]
artiom <arti...@yandex.ru> пишет:
> А вот про плеер возможно подробнее?
> Я mpd хочу впилить.
Обычный плеер [1] только в браузере.
> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
> ней не слышал. С ней есть какие-то проблемы?
Я сам его нашел только вчера, но отзывы о нем хорошие, вот например
известный сервис Backblaze его рекомендует [2].
> Почитал про Minio. Имеет ли смысл? Мне кажется, что в моём случае
> NextCloud будет лучше?
Пробуйте всё и выбирайте лучшее, для этого и нужны свободные программы.
[1]: https://apps.nextcloud.com/apps/audioplayer
[2]: https://www.backblaze.com/blog/backing-linux-backblaze-b2-duplicity-restic/
artiom <arti...@yandex.ru> пишет:
> А вот про плеер возможно подробнее?
> Я mpd хочу впилить.
> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
> ней не слышал. С ней есть какие-то проблемы?
известный сервис Backblaze его рекомендует [2].
> Почитал про Minio. Имеет ли смысл? Мне кажется, что в моём случае
> NextCloud будет лучше?
[1]: https://apps.nextcloud.com/apps/audioplayer
[2]: https://www.backblaze.com/blog/backing-linux-backblaze-b2-duplicity-restic/
artiom
Feb 18, 2018, 1:20:03 PM2/18/18
to
> >> >> >> - NextCloud
> >> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
> >> >> > почему называется "облаком", легко ли его интегрировать с той же Bacula
> >> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
> >> >> > использовать в составе NAS.
> >> >>
> >> >> >> - SyncThing
> >> >> > Сам уже нашёл.
> >> >> > Хотелось бы о нём услышать отзывы использующих.
> >> >> > По мне: весьма интересная штука.
> >> >>
> >> >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
> >> >>
> >> > По каким причинам?
> >> > Тут бы неплохо прояснить разницу.
> >> > Если из бэкапа требуется доставать отдельные файлы, то границу мне
> >> > сложно провести.
> >>
> >> Синхронизатор не отличает намеренное удаление или порчу от
> >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
> >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
> >> засинхронизироваться.
> >>
> > Как отличает система резервного копирования?
> > Или тоже не отличает, но это компенсируется историей бэкапов?
>
> Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
> удаляется целиком, либо (если ему повезло оказаться, например, годичным)
> хранится "вечно".
>
А какова частота полного, декремента и инкремента?
> >> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
> >> >> > почему называется "облаком", легко ли его интегрировать с той же Bacula
> >> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
> >> >> > использовать в составе NAS.
> >> >>
> >> >> >> - SyncThing
> >> >> > Сам уже нашёл.
> >> >> > Хотелось бы о нём услышать отзывы использующих.
> >> >> > По мне: весьма интересная штука.
> >> >>
> >> >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
> >> >>
> >> > По каким причинам?
> >> > Тут бы неплохо прояснить разницу.
> >> > Если из бэкапа требуется доставать отдельные файлы, то границу мне
> >> > сложно провести.
> >>
> >> Синхронизатор не отличает намеренное удаление или порчу от
> >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
> >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
> >> засинхронизироваться.
> >>
> > Как отличает система резервного копирования?
> > Или тоже не отличает, но это компенсируется историей бэкапов?
>
> Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
> удаляется целиком, либо (если ему повезло оказаться, например, годичным)
> хранится "вечно".
>
> >> >> Инкрементальный бэкап, который обеспечивает tar и основные
> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
> >> >> третье можно делать, гоняя каждый раз полный бэкап.
> >> >>
> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
> >> > (облако).
> >> > Шифровать отдельно при хранении в NAS, не требуется.
> >>
> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
> >> разные технологии бэкапа :)
> >>
> > Да, конечно, так и планировалось изначально.
>
> Минус простота настройки.
>
> >> >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
> >> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
> >> >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
> >> >> раз в некоторое время гонят полный бэкап, а между ними
> >> >> инкрементальный. tar вот даже различает дифференциальный (разница с
> >> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
> >> >> ни был). Для разумного времени восстановления характерная частота
> >> >> полного - раз в месяц, дифференциального - в неделю, инкрементального -
> >> >> ежедневно. В результате получается дорого, но не невменяемо дорого.
> >> >>
> >> > Любопытно, на основе инструментов, которые тут советовали, возможно это
> >> > построить не сильно напрягаясь?
> >>
> >> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
> >> не позволяет, его нужно выкинуть и посмотреть на другой.
> >>
> > Согласен.
> > Пока не вполне понятно, что из этого выкинуть.
> > Кроме Bacula, но тут хвалят её форки.
>
> >> На глазок, при использовании собственно tar, gpg и любого способа
> >> копирования такая конструкция собирается за неделю, включая написание
> >> регламента. Но трафика будет изрядно.
> >>
> > И не вполне портируемо.
>
> Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на
> винде не будут забэкаплены открытые в данный момент файлы.
>
отлажены, web-интерфейс есть, по фичам всё нормально и статей о нём нет
типа "О том, как я неделю вдуплял в BareOS".
> >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
> >> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
> >> >> при работе в архиве, но все же изрядная.
> >> > Она мне, в принципе, требуется.
> >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
> >> > (сейчас закончил только с музыкой и видео, проекты в нормальном
> >> > состоянии, книги и документы в процессе сортировки).
> >> > Поэтому, что бэкапить, я могу сказать.
> >>
> >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
> >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
> >>
> > Ну ok, политика и регламент бэкапа?
> > Если делать на серьёзном уровне, конечно полезно.
> > В принципе, это в любом случае полезно, так что пока ещё NAS не
> > завершён, в рамках этого проекта возможно и системой резервного
> > копирования более серьёзно заняться.
>
> Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем,
> чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
> касающейся его части.
>
слышали такое понятие, как "регламент бэкапа". Кое-что пользователю
знать не нужно.
> >> >> "Результатом автоматизации
> >> >> бардака может быть только автоматизированный бардак." В нее, в
> >> >> частности, входит периодическая тренировка восстановления из
> >> >> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
> >> >> получится восстановиться.
> >> >>
> >> > С проведением таких "учений" всё сложнее: как восстанавливать машину, на
> >> > которой постоянно работаешь (в любом случае, восстановление - потеря
> >> > времени)?
> >>
> >> Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно
> >> делаешь, либо у тебя очень невысокие шансы, что ты сможешь
> >> восстановиться в случае проблем.
> >>
> >> Вероятность того, что при первой попытке восстановления проблемы
> >> возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
> >> все же заметно больше нуля, и чем сложнее инфраструктура хранения
> >> резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
> >> аргумент в пользу решений на базе rsync, у которых на выходе такое же
> >> дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
> >> лучше, чтобы первые несколько тревог были учебными.
> >>
> > Хорошо, тогда касательно rsync: как делать дифференциальный и
> > инкрементальный бэкап?
>
> У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап,
> и потом rsync -a --delete в будущий_бэкап.
>
> Если бэкапится юниксовая машина, то вся конструкция без особых
> сложностей скриптуется с сервера, который и следит за расписанием. С
> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
> -al" и по расписанию пинал по почте владельца машины. А часть rsync
> запускает уже владелец машины.
>
> > Касательно проверок: как это делается?
> > На практике, там где это было, как проводится такая проверка в
> > существующей инфраструктуре?
>
> Тупо и цинично. Берется специальная тренировочная машина, типа с пустым
> диском (обычно виртуалка, но по возможности иногда и на железе стоит
> прогнать), и на нее выполняется регламент восстановления. Если не
> сработал - все бросаем, чиним, корректируем регламент.
>
> Если речь идет о восстановлении пользовательских данных, а не всей
> системы, то машина берется не пустая, а с установленной ОС. В этом
> случае регламент восстановления должен включать установку необходимого
> софта поверх базовой установки ОС (буде он нужен), если он еще не
> установлен. Это тоже надо проверять, а то разное может получиться.
>
основной инфраструктуры ради проверки восстановления не прерывается.
artiom
Feb 18, 2018, 1:30:02 PM2/18/18
to
17.02.2018 19:19, Artem Chuprina пишет:
Пользователи, как правило, не создают контент.
Потому, файлы (и, тем более, блоки) часто дублируются.
> Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
> политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
> 15). Но не в 50.
>
artiom
Feb 18, 2018, 1:40:02 PM2/18/18
to
так и нужно.
Возможно, конечно, бороться "антивирусными" мерами...
> Ну и думай, что дороже: дополнительное дисковое пространство для
> хранения бэкапа системы, или твои время и нервы на более сложную
> процедуру восстановления.
>
пространства хранилища, какие-то 50 Гб на машину странно.
С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
накатил свежую ОС, накатил конфигурацию и пакеты, всё.
Кроме того,
> > - В этой старой системе я хочу многое переделать, например дисковую
> > организацию, что потребует переустановки при сохранении большинства
> > конфигов.
>
> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
> перегенерировал initrd из чрута до первой перезагрузки, если в разметке
> добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
>
старых версий (это ещё squeeze) что-то определённо тянется. Но там пока
до обновления или переустановки далеко, я ещё не решил, как буду делать.
> >> >> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
> >> >> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
> >> >> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
> >> >> машин и есть человек, который регулярно подкручивает эту конструкцию. С
> >> >> квалификацией админа и наличием _регулярно_ времени на эту работу.
> >> >>
> >> > Насколько регулярно и насколько велик объём донастройки?
> >>
> >> Мне пока не доводилось работать в таком месте, где работодатель считал
> >> бы, что это ему по карману :)
> >>
> > Если я делаю для себя, читается, как: "Ты не будешь этим заниматься"?
>
> Скорее всего, да. У тебя же есть и другие занятия, а ты у себя один. И
> кушать хочешь три раза в день, вероятно.
>
вариант. Сложен и запутан.
> >> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
> >> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
> >> и набор пакетов привел меня к выводу, что потребуется специальный
> >> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
> >> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
> >> виртуалки с виндой.
> >>
> > А форки, которые здесь рекламируют?
> > http://www.urbackup.org/
> > https://time404.ru/1776/
>
> А можно я не буду на них смотреть? Но по идее, если форк, тем более
> более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд
> ли система с тех пор стала сильно проще...
>
> >> Ну, то есть, конторы, где эти или подобные технологии применялись, я
> >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
> >> раз - только потому, что у меня был еще и свой бэкап.
> >>
> > Но ведь система специально заточена под бэкап, долго живёт и развивается.
> > Почему не было успешно её применение?
> > Возможно ли, что это просто было неправильное использование?
>
> Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
>
artiom
Feb 18, 2018, 2:30:02 PM2/18/18
to
>> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
>> ней не слышал. С ней есть какие-то проблемы?
>
> Я сам его нашел только вчера, но отзывы о нем хорошие, вот например
> известный сервис Backblaze его рекомендует [2].
>
Любопытно, что рекомендуют, статистику по дискам их я использовал:
>> ней не слышал. С ней есть какие-то проблемы?
>
> Я сам его нашел только вчера, но отзывы о нем хорошие, вот например
> известный сервис Backblaze его рекомендует [2].
>
сервис серьёзный.
>> Почитал про Minio. Имеет ли смысл? Мне кажется, что в моём случае
>> NextCloud будет лучше?
>
> Пробуйте всё и выбирайте лучшее, для этого и нужны свободные программы.
>
> [1]: https://apps.nextcloud.com/apps/audioplayer
> [2]: https://www.backblaze.com/blog/backing-linux-backblaze-b2-duplicity-restic/
>
перейти к другим проектам.
Artem Chuprina
Feb 18, 2018, 3:10:02 PM2/18/18
to
artiom -> debian-...@lists.debian.org @ Sun, 18 Feb 2018 21:36:37 +0300:
У меня там бывают (в /usr/local/sbin) скрипты, которые использую не я, а, например, cron...
Очень не факт. Зараза с легкостью может окопаться и в /etc (в случае
винды - системном реестре).
>> Ну и думай, что дороже: дополнительное дисковое пространство для
>> хранения бэкапа системы, или твои время и нервы на более сложную
>> процедуру восстановления.
>>
> С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом
> пространства хранилища, какие-то 50 Гб на машину странно.
> С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
> накатил свежую ОС, накатил конфигурацию и пакеты, всё.
Твоих телодвижений больше. "Накатил свежую ОС" - это существенно больше
одной команды, и внимания оно хочет не единым куском, а урывками.
>> > - В этой старой системе я хочу многое переделать, например дисковую
>> > организацию, что потребует переустановки при сохранении большинства
>> > конфигов.
>>
>> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
>> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
>> перегенерировал initrd из чрута до первой перезагрузки, если в разметке
>> добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
>>
> Там много что надо поменять.
В моей практике это все же обычно лучше делать по одному блоку
функциональности за раз.
> Плюс, лишних пакетов море скопилось, со старых версий (это ещё
> squeeze) что-то определённо тянется.
dpkg -l, и вдумчиво apt-get remove --purge. Это проще, чем наоборот.
>> >> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
>> >> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
>> >> и набор пакетов привел меня к выводу, что потребуется специальный
>> >> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
>> >> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
>> >> виртуалки с виндой.
>> >>
>> > А форки, которые здесь рекламируют?
>> > http://www.urbackup.org/
>> > https://time404.ru/1776/
>>
>> А можно я не буду на них смотреть? Но по идее, если форк, тем более
>> более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд
>> ли система с тех пор стала сильно проще...
>>
> UrBackup - не форк, а отдельный инструмент.
Anyway, можно я не буду на них смотреть? У _меня_ сейчас эта задача не
стоит.
>> >> Ну, то есть, конторы, где эти или подобные технологии применялись, я
>> >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
>> >> раз - только потому, что у меня был еще и свой бэкап.
>> >>
>> > Но ведь система специально заточена под бэкап, долго живёт и развивается.
>> > Почему не было успешно её применение?
>> > Возможно ли, что это просто было неправильное использование?
>>
>> Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
>>
> В таком случае, по каким причинам они выбирают Bacula-like?
Не могу дать гарантированного ответа, но вероятно, купившись на
рекламные слова. Иногда еще, чтобы было чем оправдываться перед
начальством за продолбы. Типа, "мы использовали проверенный бэкапный
софт, и не виноваты, что не смогли восстановить требуемое". Если тот же
самый продолб (он обычно организационного характера) произойдет с
велосипедным решением, оправдываться будет сложнее.
винды - системном реестре).
>> Ну и думай, что дороже: дополнительное дисковое пространство для
>> хранения бэкапа системы, или твои время и нервы на более сложную
>> процедуру восстановления.
>>
> С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом
> пространства хранилища, какие-то 50 Гб на машину странно.
> С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
> накатил свежую ОС, накатил конфигурацию и пакеты, всё.
одной команды, и внимания оно хочет не единым куском, а урывками.
>> > - В этой старой системе я хочу многое переделать, например дисковую
>> > организацию, что потребует переустановки при сохранении большинства
>> > конфигов.
>>
>> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
>> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
>> перегенерировал initrd из чрута до первой перезагрузки, если в разметке
>> добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
>>
> Там много что надо поменять.
функциональности за раз.
> Плюс, лишних пакетов море скопилось, со старых версий (это ещё
> squeeze) что-то определённо тянется.
>> >> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
>> >> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
>> >> и набор пакетов привел меня к выводу, что потребуется специальный
>> >> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
>> >> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
>> >> виртуалки с виндой.
>> >>
>> > А форки, которые здесь рекламируют?
>> > http://www.urbackup.org/
>> > https://time404.ru/1776/
>>
>> А можно я не буду на них смотреть? Но по идее, если форк, тем более
>> более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд
>> ли система с тех пор стала сильно проще...
>>
> UrBackup - не форк, а отдельный инструмент.
стоит.
>> >> Ну, то есть, конторы, где эти или подобные технологии применялись, я
>> >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
>> >> раз - только потому, что у меня был еще и свой бэкап.
>> >>
>> > Но ведь система специально заточена под бэкап, долго живёт и развивается.
>> > Почему не было успешно её применение?
>> > Возможно ли, что это просто было неправильное использование?
>>
>> Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
>>
> В таком случае, по каким причинам они выбирают Bacula-like?
рекламные слова. Иногда еще, чтобы было чем оправдываться перед
начальством за продолбы. Типа, "мы использовали проверенный бэкапный
софт, и не виноваты, что не смогли восстановить требуемое". Если тот же
самый продолб (он обычно организационного характера) произойдет с
велосипедным решением, оправдываться будет сложнее.
Artem Chuprina
Feb 18, 2018, 3:10:02 PM2/18/18
to
artiom -> debian-...@lists.debian.org @ Sun, 18 Feb 2018 21:23:52 +0300:
На файлопомойках пользователи как раз обычно создают контент. Если не
сам контент целиком, то выборка-то у всех разная. И для 50-кратного
дублирования надо устраивать очень специфический набор пользователей. Я
бы, пожалуй, взялся только роботами такое обеспечить, причем специально
криво написанными.
>> Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
>> политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
>> 15). Но не в 50.
>>
> Ещё неплохо, чтобы дедупликация делалась на клиенте.
Тут, кстати, палка как минимум о двух концах. Я, например, дома
предпочитаю, чтобы отобранные фотографии из поездок хранились отдельно
от совпадающих с ними файлов из подборки оригиналов даже в бэкапе. Из
соображений "в случае сбоя диска будет второй экземпляр". Если сделать
полную дедупликацию, сбой диска убьет единственный.
сам контент целиком, то выборка-то у всех разная. И для 50-кратного
дублирования надо устраивать очень специфический набор пользователей. Я
бы, пожалуй, взялся только роботами такое обеспечить, причем специально
криво написанными.
>> Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
>> политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
>> 15). Но не в 50.
>>
> Ещё неплохо, чтобы дедупликация делалась на клиенте.
предпочитаю, чтобы отобранные фотографии из поездок хранились отдельно
от совпадающих с ними файлов из подборки оригиналов даже в бэкапе. Из
соображений "в случае сбоя диска будет второй экземпляр". Если сделать
полную дедупликацию, сбой диска убьет единственный.
Artem Chuprina
Feb 18, 2018, 3:40:03 PM2/18/18
to
artiom -> debian-...@lists.debian.org @ Sun, 18 Feb 2018 21:15:25 +0300:
>> >> Синхронизатор не отличает намеренное удаление или порчу от
>> >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
>> >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
>> >> засинхронизироваться.
>> >>
>> > Как отличает система резервного копирования?
>> > Или тоже не отличает, но это компенсируется историей бэкапов?
>>
>> Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
>> удаляется целиком, либо (если ему повезло оказаться, например, годичным)
>> хранится "вечно".
>>
> А какова частота полного, декремента и инкремента?
Зависит от характера изменения данных. На работе бэкап делался ежедневно
- восстанавливать работу всей конторы за неделю было сложно, поскольку
задач много, и за неделю тупо успеваешь забыть, что делал, не то что
как. Дома делается раз в неделю. Это, если применяются инкрементные,
частота инкрементных (у меня довольно давно применяются
обратно-инкрементные, там бэкап бывает только одного типа).
Если же говорить о декрементных и полных, то тут вопрос баланса трафика
туда и времени восстановления. Я бы сказал, что полные следует делать
настолько часто, насколько позволяет жаба по трафику. Деление на
декремент и инкремент проводить скорее из соображений "больше десятка
инкрементов за одну операцию восстановления не офигеть как удобно
накатывать". В man tar приводился для прикидки вариант "полные раз в
месяц, декременты раз в неделю, инкременты раз в день". Тогда при
восстановлении накатывается один полный, один декремент (он по
определению один) и не больше 6 инкрементов.
>> >> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >> >>
>> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> >> > (облако).
>> >> > Шифровать отдельно при хранении в NAS, не требуется.
>> >>
>> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> >> разные технологии бэкапа :)
>> >>
>> > Да, конечно, так и планировалось изначально.
>>
>> Минус простота настройки.
>>
> В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
В изначальной постановке задачи простота настройки была одним из условий :)
Я не имею цели отвратить тебя от urbackup. Которого я в глаза не видел.
>> >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> >> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> >> >> при работе в архиве, но все же изрядная.
>> >> > Она мне, в принципе, требуется.
>> >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
>> >> > (сейчас закончил только с музыкой и видео, проекты в нормальном
>> >> > состоянии, книги и документы в процессе сортировки).
>> >> > Поэтому, что бэкапить, я могу сказать.
>> >>
>> >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
>> >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>> >>
>> > Ну ok, политика и регламент бэкапа?
>> > Если делать на серьёзном уровне, конечно полезно.
>> > В принципе, это в любом случае полезно, так что пока ещё NAS не
>> > завершён, в рамках этого проекта возможно и системой резервного
>> > копирования более серьёзно заняться.
>>
>> Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем,
>> чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
>> касающейся его части.
>>
> Т.е. мной. Кроме того, я почему-то сомневаюсь, что в компаниях все
> слышали такое понятие, как "регламент бэкапа". Кое-что пользователю
> знать не нужно.
А есть разные регламенты. Для админа, настраивающего бэкап, для админа,
следящего за бэкапами, и для пользователя, желающего, чтобы его данные
и/или систему в случае сбоев можно было восстановить.
Мне не попадалось ситуаций, где бы все данные, ценные для пользователя,
удавалось отследить и забэкапить без его осознанного участия. Кроме
конструкций с бездисковыми X-терминалами в конце 90-х - начале 2000-х,
когда все данные, а зачастую и ОС терминала хранились на одном сервере и
только на нем. Повторюсь,
>> >> >> "Результатом автоматизации
>> >> >> бардака может быть только автоматизированный бардак."
>> Если бэкапится юниксовая машина, то вся конструкция без особых
>> сложностей скриптуется с сервера, который и следит за расписанием. С
>> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
>> -al" и по расписанию пинал по почте владельца машины. А часть rsync
>> запускает уже владелец машины.
>>
> Как понять "скриптуется с сервера"?
Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую
мы бэкапим) с точки зрения rsync является сервером.
>> > Касательно проверок: как это делается?
>> > На практике, там где это было, как проводится такая проверка в
>> > существующей инфраструктуре?
>>
>> Тупо и цинично. Берется специальная тренировочная машина, типа с пустым
>> диском (обычно виртуалка, но по возможности иногда и на железе стоит
>> прогнать), и на нее выполняется регламент восстановления. Если не
>> сработал - все бросаем, чиним, корректируем регламент.
>>
>> Если речь идет о восстановлении пользовательских данных, а не всей
>> системы, то машина берется не пустая, а с установленной ОС. В этом
>> случае регламент восстановления должен включать установку необходимого
>> софта поверх базовой установки ОС (буде он нужен), если он еще не
>> установлен. Это тоже надо проверять, а то разное может получиться.
>>
> В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
> основной инфраструктуры ради проверки восстановления не прерывается.
Вообще говоря, возможны ситуации, когда приходится прерывать. Потому что
оценить результат восстановления можно только протестировав, что все
документированные функции целевой машины работают. А у нее могут быть
сетевые сервисы, которые надо проверить по тому самому имени. Для чего
"учебная" машина должна подменить в сети "боевую".
Тут можно в разных местах проводить границу, и получать разную степень
уверенности в результате. Если, скажем, восстанавливается какой-нибудь
трекер (веб-морда плюс база плюс почта), то можно в регламент
восстановления включить часть "для учебной тревоги", где расписать
перенастройку на тестовое имя хоста и на тестовый вариант рассылки по
почте (что утраивает работу по написанию регламента и в полтора-два раза
увеличивает работу по учебной тревоге). Но, скажем, проверить
работоспособность восстановленного домен-контроллера виндовой сети без
замены им настоящего я бы вот так вот сходу не взялся, так что надо
приходить ночью, когда никого нет, и выключать настоящий.
>> >> Синхронизатор не отличает намеренное удаление или порчу от
>> >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
>> >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
>> >> засинхронизироваться.
>> >>
>> > Как отличает система резервного копирования?
>> > Или тоже не отличает, но это компенсируется историей бэкапов?
>>
>> Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
>> удаляется целиком, либо (если ему повезло оказаться, например, годичным)
>> хранится "вечно".
>>
> А какова частота полного, декремента и инкремента?
- восстанавливать работу всей конторы за неделю было сложно, поскольку
задач много, и за неделю тупо успеваешь забыть, что делал, не то что
как. Дома делается раз в неделю. Это, если применяются инкрементные,
частота инкрементных (у меня довольно давно применяются
обратно-инкрементные, там бэкап бывает только одного типа).
Если же говорить о декрементных и полных, то тут вопрос баланса трафика
туда и времени восстановления. Я бы сказал, что полные следует делать
настолько часто, насколько позволяет жаба по трафику. Деление на
декремент и инкремент проводить скорее из соображений "больше десятка
инкрементов за одну операцию восстановления не офигеть как удобно
накатывать". В man tar приводился для прикидки вариант "полные раз в
месяц, декременты раз в неделю, инкременты раз в день". Тогда при
восстановлении накатывается один полный, один декремент (он по
определению один) и не больше 6 инкрементов.
>> >> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >> >>
>> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> >> > (облако).
>> >> > Шифровать отдельно при хранении в NAS, не требуется.
>> >>
>> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> >> разные технологии бэкапа :)
>> >>
>> > Да, конечно, так и планировалось изначально.
>>
>> Минус простота настройки.
>>
> В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
>> >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> >> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> >> >> при работе в архиве, но все же изрядная.
>> >> > Она мне, в принципе, требуется.
>> >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
>> >> > (сейчас закончил только с музыкой и видео, проекты в нормальном
>> >> > состоянии, книги и документы в процессе сортировки).
>> >> > Поэтому, что бэкапить, я могу сказать.
>> >>
>> >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
>> >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>> >>
>> > Ну ok, политика и регламент бэкапа?
>> > Если делать на серьёзном уровне, конечно полезно.
>> > В принципе, это в любом случае полезно, так что пока ещё NAS не
>> > завершён, в рамках этого проекта возможно и системой резервного
>> > копирования более серьёзно заняться.
>>
>> Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем,
>> чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
>> касающейся его части.
>>
> Т.е. мной. Кроме того, я почему-то сомневаюсь, что в компаниях все
> слышали такое понятие, как "регламент бэкапа". Кое-что пользователю
> знать не нужно.
следящего за бэкапами, и для пользователя, желающего, чтобы его данные
и/или систему в случае сбоев можно было восстановить.
Мне не попадалось ситуаций, где бы все данные, ценные для пользователя,
удавалось отследить и забэкапить без его осознанного участия. Кроме
конструкций с бездисковыми X-терминалами в конце 90-х - начале 2000-х,
когда все данные, а зачастую и ОС терминала хранились на одном сервере и
только на нем. Повторюсь,
>> >> >> "Результатом автоматизации
>> >> >> бардака может быть только автоматизированный бардак."
>> > Хорошо, тогда касательно rsync: как делать дифференциальный и
>> > инкрементальный бэкап?
>>
>> У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап,
>> и потом rsync -a --delete в будущий_бэкап.
>>
> А про упомянутый тут restic можете что-то сказать?
Не могу.
>> > инкрементальный бэкап?
>>
>> У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап,
>> и потом rsync -a --delete в будущий_бэкап.
>>
> А про упомянутый тут restic можете что-то сказать?
>> Если бэкапится юниксовая машина, то вся конструкция без особых
>> сложностей скриптуется с сервера, который и следит за расписанием. С
>> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
>> -al" и по расписанию пинал по почте владельца машины. А часть rsync
>> запускает уже владелец машины.
>>
> Как понять "скриптуется с сервера"?
мы бэкапим) с точки зрения rsync является сервером.
>> > Касательно проверок: как это делается?
>> > На практике, там где это было, как проводится такая проверка в
>> > существующей инфраструктуре?
>>
>> Тупо и цинично. Берется специальная тренировочная машина, типа с пустым
>> диском (обычно виртуалка, но по возможности иногда и на железе стоит
>> прогнать), и на нее выполняется регламент восстановления. Если не
>> сработал - все бросаем, чиним, корректируем регламент.
>>
>> Если речь идет о восстановлении пользовательских данных, а не всей
>> системы, то машина берется не пустая, а с установленной ОС. В этом
>> случае регламент восстановления должен включать установку необходимого
>> софта поверх базовой установки ОС (буде он нужен), если он еще не
>> установлен. Это тоже надо проверять, а то разное может получиться.
>>
> В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
> основной инфраструктуры ради проверки восстановления не прерывается.
оценить результат восстановления можно только протестировав, что все
документированные функции целевой машины работают. А у нее могут быть
сетевые сервисы, которые надо проверить по тому самому имени. Для чего
"учебная" машина должна подменить в сети "боевую".
Тут можно в разных местах проводить границу, и получать разную степень
уверенности в результате. Если, скажем, восстанавливается какой-нибудь
трекер (веб-морда плюс база плюс почта), то можно в регламент
восстановления включить часть "для учебной тревоги", где расписать
перенастройку на тестовое имя хоста и на тестовый вариант рассылки по
почте (что утраивает работу по написанию регламента и в полтора-два раза
увеличивает работу по учебной тревоге). Но, скажем, проверить
работоспособность восстановленного домен-контроллера виндовой сети без
замены им настоящего я бы вот так вот сходу не взялся, так что надо
приходить ночью, когда никого нет, и выключать настоящий.
Dmitry Nezhevenko
Feb 19, 2018, 6:30:03 AM2/19/18
to
On Sat, Feb 17, 2018 at 11:29:16PM +0300, artiom wrote:
> >
> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
> ней не слышал. С ней есть какие-то проблемы?
Использую сейчас restic для бэкапа пары ноутбуков плюс домашнего NAS.
> >
> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
> ней не слышал. С ней есть какие-то проблемы?
Файлы достаточно сильно пересекаются, так что дедупликация очень сильно
экономит место (репозиторий около 1.5 TB, до этого пользовался
rdiff-backup и в сумме получалось около 2.5 TB). И это при том что restic
не умеет сжатие. Вообще никак.
Из плюсов что увидел для себя:
1. Дедупликация. Это действительно очень удобно. До этого пытался руками
отслеживать 'общие' каталоги на разных устройствах. Теперь это всё
происходит автоматом. Экономится и трафик (если большой файл есть на двух
хостах, то в хранилище его зальет кто-то один). Дедупликация на блочном
уровне, так что нет никаких проблем с переименованием/перемещением файлов,
нет проблем с образами виртуалок.
2. Нет понятия полного/инкрементального бэкапа. Все они равноценные. По
сети всегда гоняются только новые блоки.
3. Все данные и метаданные у restic с контрольными суммами. 'restic check
--read-data' может подтвердить, что бэкап полностью целый и с него 100%
что можно восстановиться.
4. Стореджем может быть что угодно (sftp, webdav, всякие s3, backblaze).
Сервера, как такового, нет.
Минусы:
1. Оно очень сильно кушает RAM на клиенте. При чем потребление
пропорционально общему размеру репозитория. Для моих 1.5TB данных это
около 4GB RAM при бэкапе.
2. Не умеет бэкапить ACL, extended attributes.
3 Удаление ненужных бэкапов (точнее prune, освобождение места после них) --
штука медленная и, опять же, кушающая много RAM. При этом во время prune
никто не может бэкапиться в этот же репозиторий.
4. Ключи шифрования одни на все хосты (в общем случае любой хост может
прочитать бэкапы 'соседей'). Если сильно нужно и бэкап на 'свой' сервер,
то решается с помощью rest-server --append-only.
5. Восстановление с помощью 'restic restore' очень медленное. Но есть fuse
mount, который просто показывает бэкапы в виде иерархии host/дата.
Я для себя решил что мне более важен удобный backup чем restore.
--
WBR, Dmitry
Victor Wagner
Feb 19, 2018, 6:50:02 AM2/19/18
to
On Sun, 18 Feb 2018 23:34:56 +0300
Artem Chuprina <r...@lasgalen.net> wrote:
> > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
> > основной инфраструктуры ради проверки восстановления не
> > прерывается.
>
> Вообще говоря, возможны ситуации, когда приходится прерывать. Потому
> что оценить результат восстановления можно только протестировав, что
> все документированные функции целевой машины работают. А у нее могут
> быть сетевые сервисы, которые надо проверить по тому самому имени.
> Для чего "учебная" машина должна подменить в сети "боевую".
А я вот подумал - а не дешевле ли будет подсунуть учебной
Artem Chuprina <r...@lasgalen.net> wrote:
> > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
> > основной инфраструктуры ради проверки восстановления не
> > прерывается.
>
> Вообще говоря, возможны ситуации, когда приходится прерывать. Потому
> что оценить результат восстановления можно только протестировав, что
> все документированные функции целевой машины работают. А у нее могут
> быть сетевые сервисы, которые надо проверить по тому самому имени.
> Для чего "учебная" машина должна подменить в сети "боевую".
восстанавливаемой машине учебный интернет с учебными DNS-ами и учебным
mx-ом? Ну и парочкой учебных рабочих станций, куда админ после
восстановления может зайти и обратиться ко всем сервисам, которые надо.
Понятно, что это тоже излишние трудозатраты на учебную тревогу. Зато
результаты работы проверяются корректно, а учебная сеть делается один
раз на все бэкапимые машины.
--
Artem Chuprina
Feb 19, 2018, 8:40:03 AM2/19/18
to
Коротаев Руслан
Feb 20, 2018, 9:20:02 AM2/20/18
to
В сообщении от [Пн 2018-02-19 12:58 +0200]
Dmitry Nezhevenko <di...@dion.org.ua> пишет:
> Оно очень сильно кушает RAM на клиенте. При чем потребление
> пропорционально общему размеру репозитория. Для моих 1.5TB данных это
> около 4GB RAM при бэкапе.
Спасибо, хороший обзор. Вопрос: а может это Page Cache? Посмотрите вывод
команды free, если память потребляется за счет buff/cache, то всё в
порядке. У меня на виртуалке крутится Minio (прога схожая по
функциональности с restic и также написана Go), почти вся память уходит
в Page Cache.
> Ключи шифрования одни на все хосты (в общем случае любой хост может
> прочитать бэкапы 'соседей').
Можно сделать репозиторий под каждый хост, но тогда теряются
преимущества дедупликации. С точки зрения S3 и Minio, репозиторий это
просто bucket, мне кажется здесь нужно найти компромисс между
безопасностью и удобством.
> Удаление ненужных бэкапов (точнее prune, освобождение места после них)
> -- штука медленная... Восстановление с помощью 'restic restore' очень
> медленное.
На сайте restic сказано [1], что он хранит временные файлы и кэш в
директориях по умолчанию, но их можно переназначить. Было бы интересно
заменить их на SSD-диск и посмотреть насколько улучшилась
производительность (конечно если у вас есть такая возможность).
[1]: https://restic.readthedocs.io/en/stable/manual_rest.html
Dmitry Nezhevenko <di...@dion.org.ua> пишет:
> Оно очень сильно кушает RAM на клиенте. При чем потребление
> пропорционально общему размеру репозитория. Для моих 1.5TB данных это
> около 4GB RAM при бэкапе.
команды free, если память потребляется за счет buff/cache, то всё в
порядке. У меня на виртуалке крутится Minio (прога схожая по
функциональности с restic и также написана Go), почти вся память уходит
в Page Cache.
> Ключи шифрования одни на все хосты (в общем случае любой хост может
> прочитать бэкапы 'соседей').
преимущества дедупликации. С точки зрения S3 и Minio, репозиторий это
просто bucket, мне кажется здесь нужно найти компромисс между
безопасностью и удобством.
> Удаление ненужных бэкапов (точнее prune, освобождение места после них)
> медленное.
На сайте restic сказано [1], что он хранит временные файлы и кэш в
директориях по умолчанию, но их можно переназначить. Было бы интересно
заменить их на SSD-диск и посмотреть насколько улучшилась
производительность (конечно если у вас есть такая возможность).
[1]: https://restic.readthedocs.io/en/stable/manual_rest.html
Dmitry Nezhevenko
Feb 20, 2018, 9:40:02 AM2/20/18
to
On Tue, Feb 20, 2018 at 07:10:24PM +0500, Коротаев Руслан wrote:
> Спасибо, хороший обзор. Вопрос: а может это Page Cache? Посмотрите вывод
> команды free, если память потребляется за счет buff/cache, то всё в
> порядке. У меня на виртуалке крутится Minio (прога схожая по
> функциональности с restic и также написана Go), почти вся память уходит
> в Page Cache.
Нет. Это не Page Cache. Память уходит на внутренние индексы restic и
> Спасибо, хороший обзор. Вопрос: а может это Page Cache? Посмотрите вывод
> команды free, если память потребляется за счет buff/cache, то всё в
> порядке. У меня на виртуалке крутится Minio (прога схожая по
> функциональности с restic и также написана Go), почти вся память уходит
> в Page Cache.
растет с ростом репозитория. Грубо говоря что-то мелкое вродее Raspberry
Pi сейчас невозможно забэкапить на терабайтный репозиторий.
Но планы починить это у авторов есть.
> > Ключи шифрования одни на все хосты (в общем случае любой хост может
> > прочитать бэкапы 'соседей').
>
> Можно сделать репозиторий под каждый хост, но тогда теряются
> преимущества дедупликации. С точки зрения S3 и Minio, репозиторий это
> просто bucket, мне кажется здесь нужно найти компромисс между
> безопасностью и удобством.
домашнем NAS. При этом хранилище расшарено используя rest-server с
ключиком --append-only ( https://github.com/restic/rest-server ). В таком
случае даже имея ключ/пароль можно только дописывать данные. Прочитать/удалить
ничего нельзя.
Все другие операции (prune, восстановление) я делаю на самом NAS, указывая
в качестве репозитория каталог на диске.
Ну а по крону хранилище синхронизируется с облаком (backblaze).
>
> > Удаление ненужных бэкапов (точнее prune, освобождение места после них)
> > -- штука медленная... Восстановление с помощью 'restic restore' очень
> > медленное.
>
> На сайте restic сказано [1], что он хранит временные файлы и кэш в
> директориях по умолчанию, но их можно переназначить. Было бы интересно
> заменить их на SSD-диск и посмотреть насколько улучшилась
> производительность (конечно если у вас есть такая возможность).
(пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
SSD.
--
WBR, Dmitry
Коротаев Руслан
Feb 20, 2018, 10:20:03 AM2/20/18
to
В сообщении от [Вт 2018-02-20 16:34 +0200]
Dmitry Nezhevenko <di...@dion.org.ua> пишет:
> Нет. Это не Page Cache. Память уходит на внутренние индексы restic и
> растет с ростом репозитория. Грубо говоря что-то мелкое вродее Raspberry
> Pi сейчас невозможно забэкапить на терабайтный репозиторий.
>
> Но планы починить это у авторов есть.
но видимо придется подождать когда они всё допилят.
Dmitry Nezhevenko <di...@dion.org.ua> пишет:
> Нет. Это не Page Cache. Память уходит на внутренние индексы restic и
> растет с ростом репозитория. Грубо говоря что-то мелкое вродее Raspberry
> Pi сейчас невозможно забэкапить на терабайтный репозиторий.
>
> Но планы починить это у авторов есть.
> prune по умолчанию не использует кэш. Он чем-то похож на git repack
> (пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
> весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
> SSD.
Ясно. Тогда остаюсь на Minio, хотел использовать restic для шифрования,
> (пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
> весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
> SSD.
но видимо придется подождать когда они всё допилят.
Dmitry Nezhevenko
Feb 20, 2018, 11:00:02 AM2/20/18
to
On Tue, Feb 20, 2018 at 08:10:24PM +0500, Коротаев Руслан wrote:
> > prune по умолчанию не использует кэш. Он чем-то похож на git repack
> > (пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
> > весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
> > SSD.
>
> Ясно. Тогда остаюсь на Minio, хотел использовать restic для шифрования,
> но видимо придется подождать когда они всё допилят.
>
А при чем тут minio? restic -- средство бэкапа, а minio -- просто
> > prune по умолчанию не использует кэш. Он чем-то похож на git repack
> > (пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
> > весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
> > SSD.
>
> Ясно. Тогда остаюсь на Minio, хотел использовать restic для шифрования,
> но видимо придется подождать когда они всё допилят.
>
хранилище файлов.
--
WBR, Dmitry
Коротаев Руслан
Feb 20, 2018, 11:20:03 AM2/20/18
to
В сообщении от [Вт 2018-02-20 17:51 +0200]
Dmitry Nezhevenko <di...@dion.org.ua> пишет:
> А при чем тут minio? restic -- средство бэкапа, а minio -- просто
> хранилище файлов.
Не только, ещё есть клиент [1], можно легко перемещать данные между
облаками, но нет шифрования и снапшотов как в restic.
[1]: https://docs.minio.io/docs/minio-client-quickstart-guide
Dmitry Nezhevenko <di...@dion.org.ua> пишет:
> А при чем тут minio? restic -- средство бэкапа, а minio -- просто
> хранилище файлов.
облаками, но нет шифрования и снапшотов как в restic.
[1]: https://docs.minio.io/docs/minio-client-quickstart-guide
artiom
Feb 20, 2018, 12:50:03 PM2/20/18
to
20.02.2018 18:10, Коротаев Руслан пишет:
Почему вообще объектное хранилище?
artiom
Feb 20, 2018, 12:50:03 PM2/20/18
to
19.02.2018 13:58, Dmitry Nezhevenko пишет:
Любопытно, а в составе какого-нибудь BackupPC его возможно использовать?
artiom
Feb 20, 2018, 1:00:02 PM2/20/18
to
обойдётся без проверки перенастроек после бэкапа (тестовую машину
возможно будет выделить, в принципе).
artiom
Feb 20, 2018, 1:00:02 PM2/20/18
to
18.02.2018 23:07, Artem Chuprina пишет:
> >> Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
> >> политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
> >> 15). Но не в 50.
> >>
> > Ещё неплохо, чтобы дедупликация делалась на клиенте.
>
> Тут, кстати, палка как минимум о двух концах. Я, например, дома
> предпочитаю, чтобы отобранные фотографии из поездок хранились отдельно
> от совпадающих с ними файлов из подборки оригиналов даже в бэкапе. Из
> соображений "в случае сбоя диска будет второй экземпляр". Если сделать
> полную дедупликацию, сбой диска убьет единственный.
>
целом, я считаю, подход неправильный.
Надёжность хранилища должна нижним уровнем обеспечиваться.
Явно не прикладным, на котором работает система резервного копирования.
artiom
Feb 20, 2018, 1:10:03 PM2/20/18
to
равно файл нужен, который будет запускаться, разве нет?
> >> Ну и думай, что дороже: дополнительное дисковое пространство для
> >> хранения бэкапа системы, или твои время и нервы на более сложную
> >> процедуру восстановления.
> >>
> > С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом
> > пространства хранилища, какие-то 50 Гб на машину странно.
> > С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
> > накатил свежую ОС, накатил конфигурацию и пакеты, всё.
>
> Твоих телодвижений больше. "Накатил свежую ОС" - это существенно больше
> одной команды, и внимания оно хочет не единым куском, а урывками.
>
как сделать, я принять не могу. У обоих подходов есть плюсы и минусы.
> >> > - В этой старой системе я хочу многое переделать, например дисковую
> >> > организацию, что потребует переустановки при сохранении большинства
> >> > конфигов.
> >>
> >> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
> >> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
> >> перегенерировал initrd из чрута до первой перезагрузки, если в разметке
> >> добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
> >>
> > Там много что надо поменять.
>
> В моей практике это все же обычно лучше делать по одному блоку
> функциональности за раз.
>> > Плюс, лишних пакетов море скопилось, со старых версий (это ещё
> > squeeze) что-то определённо тянется.
>
> dpkg -l, и вдумчиво apt-get remove --purge. Это проще, чем наоборот.
>
задачами NAS разберусь, я этим заниматься не буду.
> >> >> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
> >> >> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
> >> >> и набор пакетов привел меня к выводу, что потребуется специальный
> >> >> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
> >> >> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
> >> >> виртуалки с виндой.
> >> >>
> >> > А форки, которые здесь рекламируют?
> >> > http://www.urbackup.org/
> >> > https://time404.ru/1776/
> >>
> >> А можно я не буду на них смотреть? Но по идее, если форк, тем более
> >> более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд
> >> ли система с тех пор стала сильно проще...
> >>
> > UrBackup - не форк, а отдельный инструмент.
>
> Anyway, можно я не буду на них смотреть? У _меня_ сейчас эта задача не
> стоит.
>
Другое дело, что не tar-ом единым.
Есть инструмент, о котором в целом, положительные отзывы, который легко
интегрируется во FreeNAS, по списку фич удовлетворят моим потребностям:
зачем же мне делать на rsync и подпиливать всякие WEB-интерфейсы
самостоятельно (пусть, даже разбираться с тем же BackupPC)?
> >> >> Ну, то есть, конторы, где эти или подобные технологии применялись, я
> >> >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
> >> >> раз - только потому, что у меня был еще и свой бэкап.
> >> >>
> >> > Но ведь система специально заточена под бэкап, долго живёт и развивается.
> >> > Почему не было успешно её применение?
> >> > Возможно ли, что это просто было неправильное использование?
> >>
> >> Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
> >>
> > В таком случае, по каким причинам они выбирают Bacula-like?
>
> Не могу дать гарантированного ответа, но вероятно, купившись на
> рекламные слова. Иногда еще, чтобы было чем оправдываться перед
> начальством за продолбы. Типа, "мы использовали проверенный бэкапный
> софт, и не виноваты, что не смогли восстановить требуемое". Если тот же
> самый продолб (он обычно организационного характера) произойдет с
> велосипедным решением, оправдываться будет сложнее.
>
artiom
Feb 20, 2018, 1:10:03 PM2/20/18
to
> >> >> >> Инкрементальный бэкап, который обеспечивает tar и основные
> >> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
> >> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
> >> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
> >> >> >> третье можно делать, гоняя каждый раз полный бэкап.
> >> >> >>
> >> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
> >> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
> >> >> > (облако).
> >> >> > Шифровать отдельно при хранении в NAS, не требуется.
> >> >>
> >> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
> >> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
> >> >> разные технологии бэкапа :)
> >> >>
> >> > Да, конечно, так и планировалось изначально.
> >>
> >> Минус простота настройки.
> >>
> > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
>
> В изначальной постановке задачи простота настройки была одним из условий :)
>
Да нет же.
> >> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
> >> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
> >> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
> >> >> >> третье можно делать, гоняя каждый раз полный бэкап.
> >> >> >>
> >> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
> >> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
> >> >> > (облако).
> >> >> > Шифровать отдельно при хранении в NAS, не требуется.
> >> >>
> >> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
> >> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
> >> >> разные технологии бэкапа :)
> >> >>
> >> > Да, конечно, так и планировалось изначально.
> >>
> >> Минус простота настройки.
> >>
> > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
>
> В изначальной постановке задачи простота настройки была одним из условий :)
>
В изначальной постановке задачи было: "Минимум ручной допилки и сложной
настройки на сервере".
Т.е., не приветствуется, но разумный минимум, меньше которого сделать не
получится (или это приведёт к установке неоправданно внутренне сложной
системы), принимается.
подобном) и на рабочем столе.
Ну т.е., есть некоторые умолчания. А если нужна кастомизация, то это уже
отдельная задача.
> >> Если бэкапится юниксовая машина, то вся конструкция без особых
> >> сложностей скриптуется с сервера, который и следит за расписанием. С
> >> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
> >> -al" и по расписанию пинал по почте владельца машины. А часть rsync
> >> запускает уже владелец машины.
> >>
> > Как понять "скриптуется с сервера"?
>
> Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую
> мы бэкапим) с точки зрения rsync является сервером.
>
Вообще, BackupPC так умеет. Он безагентный, использует rsync для *nix,
но почему-то мне кажется, что система с агентами более гибка.
Victor Wagner
Feb 21, 2018, 12:10:03 AM2/21/18
to
В Tue, 20 Feb 2018 20:56:03 +0300
artiom <arti...@yandex.ru> пишет:
ю, сбой диска убьет
> > единственный.
> Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в
> целом, я считаю, подход неправильный.
> Надёжность хранилища должна нижним уровнем обеспечиваться.
> Явно не прикладным, на котором работает система резервного
> копирования.
Нет, именно на прикладном - единственный способ обеспечить надежность
за разумные деньги.
Тем более, что на прикладном уровне мы можем защищаться от таких угроз
как "разряд высокого напряжения попал в розетки и убил всю включенную
электронику в здании" (путем хранения бэкапа на физически отключенном
устройстве) и даже от угроз "пожар" и "падение атомной бомбы на город"
(путем хранения одной из копий в географически удаленной локации)
Очевидно, что борьба с этими угрозами на нижнем уровне с одной стороны
обходится бессмысленно дорого, а с другой - порождает новые угрозы.
--
Victor Wagner <vi...@wagner.pp.ru>
artiom <arti...@yandex.ru> пишет:
ю, сбой диска убьет
> > единственный.
> Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в
> целом, я считаю, подход неправильный.
> Надёжность хранилища должна нижним уровнем обеспечиваться.
> Явно не прикладным, на котором работает система резервного
> копирования.
за разумные деньги.
Тем более, что на прикладном уровне мы можем защищаться от таких угроз
как "разряд высокого напряжения попал в розетки и убил всю включенную
электронику в здании" (путем хранения бэкапа на физически отключенном
устройстве) и даже от угроз "пожар" и "падение атомной бомбы на город"
(путем хранения одной из копий в географически удаленной локации)
Очевидно, что борьба с этими угрозами на нижнем уровне с одной стороны
обходится бессмысленно дорого, а с другой - порождает новые угрозы.
--
Victor Wagner <vi...@wagner.pp.ru>
artiom
Feb 21, 2018, 12:40:02 AM2/21/18
to
21.02.2018 08:01, Victor Wagner пишет:
> В Tue, 20 Feb 2018 20:56:03 +0300
> artiom <arti...@yandex.ru> пишет:
>
> ю, сбой диска убьет
>>> единственный.
>> Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в
>> целом, я считаю, подход неправильный.
>> Надёжность хранилища должна нижним уровнем обеспечиваться.
>> Явно не прикладным, на котором работает система резервного
>> копирования.
>
> Нет, именно на прикладном - единственный способ обеспечить надежность
> за разумные деньги.
>
> Тем более, что на прикладном уровне мы можем защищаться от таких угроз
> как "разряд высокого напряжения попал в розетки и убил всю включенную
> электронику в здании" (путем хранения бэкапа на физически отключенном
> устройстве) и даже от угроз "пожар" и "падение атомной бомбы на город"
> (путем хранения одной из копий в географически удаленной локации)
>
Нет, подождите, во-первых Артём Чуприна, как я это понял, имел ввиду
> artiom <arti...@yandex.ru> пишет:
>
> ю, сбой диска убьет
>>> единственный.
>> Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в
>> целом, я считаю, подход неправильный.
>> Надёжность хранилища должна нижним уровнем обеспечиваться.
>> Явно не прикладным, на котором работает система резервного
>> копирования.
>
> Нет, именно на прикладном - единственный способ обеспечить надежность
> за разумные деньги.
>
> Тем более, что на прикладном уровне мы можем защищаться от таких угроз
> как "разряд высокого напряжения попал в розетки и убил всю включенную
> электронику в здании" (путем хранения бэкапа на физически отключенном
> устройстве) и даже от угроз "пожар" и "падение атомной бомбы на город"
> (путем хранения одной из копий в географически удаленной локации)
>
хранение второй копии просто в другом месте того же самого устройства.
Во-вторых, возможно это и относится к прикладному уровню (в принципе,
политику определяет и отвечает за её реализацию, т.е. выгрузку на
отдельное устройство, система резервного копирования), но это всё-таки
не совсем то.
> Очевидно, что борьба с этими угрозами на нижнем уровне с одной стороны
> обходится бессмысленно дорого, а с другой - порождает новые угрозы.
>
умрёт аппаратура, а вместе с ней ядро системы резервного копирования) и
надёжность устройства хранения, которая обеспечивается аппаратурой.
"Физический уровень" - это условный RAID (некий как-то реализованный
mirror, благодаря которому не требуется делать две копии, т.к. он делает
это сам).
Резервирование системы, в целом, может быть сделано на разных уровнях
(миграция и репликация в кластере гугла - явно не "прикладной"), но это
не тоже самое, что хранение двух копий каталога с фотографиями.
Artem Chuprina
Feb 22, 2018, 3:20:02 AM2/22/18
to
artiom -> debian-...@lists.debian.org @ Tue, 20 Feb 2018 21:07:30 +0300:
>> >> >> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> >> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >> >> >>
>> >> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> >> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> >> >> > (облако).
>> >> >> > Шифровать отдельно при хранении в NAS, не требуется.
>> >> >>
>> >> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> >> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> >> >> разные технологии бэкапа :)
>> >> >>
>> >> > Да, конечно, так и планировалось изначально.
>> >>
>> >> Минус простота настройки.
>> >>
>> > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
>>
>> В изначальной постановке задачи простота настройки была одним из условий :)
>>
> Да нет же.
> В изначальной постановке задачи было: "Минимум ручной допилки и сложной
> настройки на сервере".
> Т.е., не приветствуется, но разумный минимум, меньше которого сделать не
> получится (или это приведёт к установке неоправданно внутренне сложной
> системы), принимается.
Простота и есть разумный минимум сложности :)
Для того, чтобы данные бэкапились, пользователь должен предоставить
данные бэкапилке не формально, а фактически. Это обеспечивается только
дисциплиной.
>> >> Если бэкапится юниксовая машина, то вся конструкция без особых
>> >> сложностей скриптуется с сервера, который и следит за расписанием. С
>> >> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
>> >> -al" и по расписанию пинал по почте владельца машины. А часть rsync
>> >> запускает уже владелец машины.
>> >>
>> > Как понять "скриптуется с сервера"?
>>
>> Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую
>> мы бэкапим) с точки зрения rsync является сервером.
>>
> Ясно.
> Вообще, BackupPC так умеет. Он безагентный, использует rsync для *nix,
> но почему-то мне кажется, что система с агентами более гибка.
Зато более сложна и, соответственно, более подвержена сбоям. А от бэкапа
требуется надежность. Поэтому чем сложнее система, тем больше внимания
ей придется уделять, чтобы поддерживать ее в работоспособном
состоянии. Избыточная гибкость бывает хуже, чем недостаточная.
>> >> >> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> >> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >> >> >>
>> >> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> >> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> >> >> > (облако).
>> >> >> > Шифровать отдельно при хранении в NAS, не требуется.
>> >> >>
>> >> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> >> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> >> >> разные технологии бэкапа :)
>> >> >>
>> >> > Да, конечно, так и планировалось изначально.
>> >>
>> >> Минус простота настройки.
>> >>
>> > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
>>
>> В изначальной постановке задачи простота настройки была одним из условий :)
>>
> Да нет же.
> В изначальной постановке задачи было: "Минимум ручной допилки и сложной
> настройки на сервере".
> Т.е., не приветствуется, но разумный минимум, меньше которого сделать не
> получится (или это приведёт к установке неоправданно внутренне сложной
> системы), принимается.
данные бэкапилке не формально, а фактически. Это обеспечивается только
дисциплиной.
>> >> Если бэкапится юниксовая машина, то вся конструкция без особых
>> >> сложностей скриптуется с сервера, который и следит за расписанием. С
>> >> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
>> >> -al" и по расписанию пинал по почте владельца машины. А часть rsync
>> >> запускает уже владелец машины.
>> >>
>> > Как понять "скриптуется с сервера"?
>>
>> Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую
>> мы бэкапим) с точки зрения rsync является сервером.
>>
> Ясно.
> Вообще, BackupPC так умеет. Он безагентный, использует rsync для *nix,
> но почему-то мне кажется, что система с агентами более гибка.
требуется надежность. Поэтому чем сложнее система, тем больше внимания
ей придется уделять, чтобы поддерживать ее в работоспособном
состоянии. Избыточная гибкость бывает хуже, чем недостаточная.
Artem Chuprina
Feb 22, 2018, 3:30:02 AM2/22/18
to
artiom -> debian-...@lists.debian.org @ Tue, 20 Feb 2018 21:02:34 +0300:
Ты давно туда заглядывал? /etc чуть не наполовину состоит из исполняемых
файлов. Выполняемых при каждом старте системы или чаще. Да, обычно это
скрипты, но на вполне Тьюринг-полных языках и с удобными средствами
сетевого доступа. Бинарник (они там, кстати, часто тоже есть, хотя
обычно как раз не исполнимые) для внесения заразы не требуется.
> а в случае системного реестра, ей всё равно файл нужен, который будет
> запускаться, разве нет?
Нужен. Но это, внезапно, может оказаться вполне легитимная программа
типа Internet Explorer.
>> >> >> Ну, то есть, конторы, где эти или подобные технологии применялись, я
>> >> >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
>> >> >> раз - только потому, что у меня был еще и свой бэкап.
>> >> >>
>> >> > Но ведь система специально заточена под бэкап, долго живёт и развивается.
>> >> > Почему не было успешно её применение?
>> >> > Возможно ли, что это просто было неправильное использование?
>> >>
>> >> Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
>> >>
>> > В таком случае, по каким причинам они выбирают Bacula-like?
>>
>> Не могу дать гарантированного ответа, но вероятно, купившись на
>> рекламные слова. Иногда еще, чтобы было чем оправдываться перед
>> начальством за продолбы. Типа, "мы использовали проверенный бэкапный
>> софт, и не виноваты, что не смогли восстановить требуемое". Если тот же
>> самый продолб (он обычно организационного характера) произойдет с
>> велосипедным решением, оправдываться будет сложнее.
>>
> Разве это единственная причина?
В этом абзаце я привел две :) Так вот сходу могу привести третью (она,
по сути, модификация первой): что первое нагуглилось по запросу типа
"backup software", то и выбрали. Я думаю, при желании можно придумать
еще, но ценность ответа на вопрос ниже, чем ценность 10 минут времени,
которые съест этот процесс.
файлов. Выполняемых при каждом старте системы или чаще. Да, обычно это
скрипты, но на вполне Тьюринг-полных языках и с удобными средствами
сетевого доступа. Бинарник (они там, кстати, часто тоже есть, хотя
обычно как раз не исполнимые) для внесения заразы не требуется.
> а в случае системного реестра, ей всё равно файл нужен, который будет
> запускаться, разве нет?
типа Internet Explorer.
>> >> >> Ну, то есть, конторы, где эти или подобные технологии применялись, я
>> >> >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
>> >> >> раз - только потому, что у меня был еще и свой бэкап.
>> >> >>
>> >> > Но ведь система специально заточена под бэкап, долго живёт и развивается.
>> >> > Почему не было успешно её применение?
>> >> > Возможно ли, что это просто было неправильное использование?
>> >>
>> >> Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
>> >>
>> > В таком случае, по каким причинам они выбирают Bacula-like?
>>
>> Не могу дать гарантированного ответа, но вероятно, купившись на
>> рекламные слова. Иногда еще, чтобы было чем оправдываться перед
>> начальством за продолбы. Типа, "мы использовали проверенный бэкапный
>> софт, и не виноваты, что не смогли восстановить требуемое". Если тот же
>> самый продолб (он обычно организационного характера) произойдет с
>> велосипедным решением, оправдываться будет сложнее.
>>
> Разве это единственная причина?
по сути, модификация первой): что первое нагуглилось по запросу типа
"backup software", то и выбрали. Я думаю, при желании можно придумать
еще, но ценность ответа на вопрос ниже, чем ценность 10 минут времени,
которые съест этот процесс.
Sergey Spiridonov
Feb 28, 2018, 5:30:03 AM2/28/18
to
Привет
On Thu, 15 Feb 2018 22:59:07 +0300
artiom <arti...@yandex.ru> wrote:
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
Под описание полностью подходит backuppc. Единственное чего нет из
коробки - репликации в облако, но это несложно доделать - просто по
крону закидывать хранилище в облако.
Бэкап через Интернет и репликация в Интернет накладывает ограничение на
объём данных/ширину канала, но это не сильно зависит от приложения.
Я сам пользуюсь backuppc больше десятка лет для бэкапа до 15 машин.
--
С уважением, Сергей Спиридонов
On Thu, 15 Feb 2018 22:59:07 +0300
artiom <arti...@yandex.ru> wrote:
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
Под описание полностью подходит backuppc. Единственное чего нет из
коробки - репликации в облако, но это несложно доделать - просто по
крону закидывать хранилище в облако.
Бэкап через Интернет и репликация в Интернет накладывает ограничение на
объём данных/ширину канала, но это не сильно зависит от приложения.
Я сам пользуюсь backuppc больше десятка лет для бэкапа до 15 машин.
--
С уважением, Сергей Спиридонов
artiom
Mar 9, 2018, 5:50:03 AM3/9/18
to
Выложу своё "исследование" отдельной темой. Может кому пригодится.
28.02.2018 13:21, Sergey Spiridonov пишет:
28.02.2018 13:21, Sergey Spiridonov пишет:
0 new messages