Сервер резервных копий (бэкапов).

ogankvik · #1

Очередной шаг - создать сервер для бэкапов. Бэкапить нужно пользовательские и системные файлы. Реализация обязательно на Linux и средствами самой ОС (скриптами?). Файлы находятся на ОС Windows XP-10 + серверные.
Как вижу это я: создаю на компе с файлами учётку. Сервер в заданное время подключается по ней, использую ip или доменное имя и скачивает файлы, архивирует их (опционально) и хранит их какое-то кол-во дней.

Подскажите, как это лучше реализовать? По какому протоколу подключаться к винде?

#2

ogankvik писал(а): ↑
16 июл 2023, 19:15
Бэкапить нужно пользовательские и системные файлы. Реализация обязательно на Linux и средствами самой ОС (скриптами?). Файлы находятся на ОС Windows XP-10 + серверные.

Если под "системными" подразумевается состояние системы для быстрого восстановления - то для винды это нерешаемая задача в заданных рамках. В отличии от линукса, винда блокирует открытый файл, т.е. на работающей системе копия всегда будет неполной. Единственный способ это обойти - пользоваться средствами резервного копирования самой винды. То же самое, хоть и в меньшей степени, касается пользовательских файлов. Как минимум файлы в которых содержится реестр (то что относится к настройкам этого пользователя) скопировать не получится - винда не даст, даже админу. Пока юзер из системы не выйдет.

Единственное решение я вижу в том, чтобы использовать полноценную клиент-серверную систему резервного копирования, с агентами в винде. Что-то вроде этого: Bacula

ogankvik · #3

ок забудем про системные файлы. Пользовательские каким образом лучше скопировать на сервер бэкапов?

#4

Тоже сейчас заморочился бэкапами. ИМХО, лучше сделать наоборот:
1. На сервере бэкапов с линуксом поднять SFTP (входит в состав SSH). Можно и просто FTP, если сетка доверенная и в ней не водится всяких кулхацкеров.
2. Компы с виндой сами подключаются к серверу через rclone и заливают туда бэкапы. Бэкапы предварительно создаются консольным rar-ом. Это можно повесить на виндовый планировщик или просто воткнуть в автозапуск. Насчёт работоспособности под ХР не уверен.

У меня простейший тестовый скриптик выглядит так:

Код: Выделить всё

echo off

set copydir=C:\msm\copy
set dbdir=C:\msm\database

if not exist %copydir% then md %copydir%
rar a -ep1 %copydir%\backup.rar %dbdir%\*
rclone sync %copydir% ftp:

То есть, пакует содержимое папки C:\msm\database в архив и отправляет в заранее настроенную папку на сервере.

Плюсы такого подхода:
1. Простота настройки на винде, гибкость графика создания бэкапов (можно их паковать ночью, можно перед работой, каждый день, раз в неделю и т.д.). Можно, конечно же, синхронизировать несколько папок. Что-то паковать, что-то заливать как есть. И так далее. Архивы можно запаролить.
2. Относительная безопасность. Можно создать каждому юзеру отдельный SFTP-аккаунт (не равно аккаунту пользователя linux), чтобы он заливал файлы только в свою папку на сервере. А дальше скрипт на сервере переносит бэкапы в специальную папку, доступную только админу или доверенным лицам. Скрипт тоже выложу, если надо, не буду засорять эфир пока.

Минусы:
Сложность настройки сервера. По крайней мере, для меня, с моими скромными познаниями))) Мне вот эта инструкция помогла: https://tokmakov.msk.ru/blog/item/484
Но я таки в итоге плюнул и использую сторонний FTP-хостинг. Забыл сказать, быкаплюсь в облако.

ЗЫ. Любая критика приветствуется. Возможно, есть способ организовать бэкапы гораздо проще.

#5

2. Компы с виндой сами подключаются к серверу через rclone и заливают туда бэкапы.

Вот здесь кроется некоторая потенциальная проблема: Если несколько компов начнут стучаться одновременно на сервер, да еще у них будет достаточно большой объем для копирования, то:
1. Могут положить сеть (или сегмент в котором сервер). Или просто сильно нагрузить. А контролировать такую нагрузку может быть сложно.
2. Такая параллельная нагрузка - это не весело еще и для дисков самого сервера. Допустим, до отказов не дойдет, но сама операция будет выполняться в несколько раз дольше чем при линейной записи (когда сервер сам стучится по машинам и забирает данные по очереди в один поток).

ogankvik,
Если просто документы, и чисто "системными средствами" - смонтировать шару через samba + rsync для самого копирования.

Можно еще пойти совсем другим путем, и попробовать приспособить syncthing. https://syncthing.net
Хотя в первую очередь это программа синхронизации папок между машинами, но она умеет в версионность (причем с разными стратегиями хранения/удаления) и однонаправленную передачу, так что для бекапа тоже может служить. Плюсом здесь будет возможность синхронизировать/бекапить даже из других офисов или дома, через интернет - без оглядки на белые IP. (Каналы связи у syncthing шифрованные, так это безопасно. Решение тоже кросплатформенное, открытое и бесплатное.) Так же нет большого риска получить многопоточную нагрузку - т.к. клиенты будут стучаться сильно в разнобой. По мере обновления файлов на них, а не все в одно время. И тротлинг там, насколько помню, тоже есть штатный, для регулировки нагрузки.

#6

Не по теме

Немного мыслей вслух. Тут Яндекс мечется туда-сюда, то ужесточает условия использования диска, то с корпоративных пользователей деньги трясёт, а теперь предлагает создать семейный аккаунт за 300 р/мес. До восьми членов семьи, каждому по терабайту Яндекс.Диска. А это 8Тб бэкапов почти бесплатно. Моя персональная жаба ликует! Но ведь опять же, или халяву прикроют, или ещё чего-нибудь нехорошее придумают...

#7

Ара Магеддон писал(а): ↑
16 июл 2023, 20:58
Но ведь опять же, или халяву прикроют, или ещё чего-нибудь нехорошее придумают...

...или тупо аккаунт отберут. У меня так мыло "отобрали" - потребовали войти через привязанный телефонный номер. Которого у меня разумеется нету и быть не может (другая страна). Без предупреждения, внезапно.

#8

slant, тоже об этом думал. Ну у меня всего 6 хостов, с которых нужно ежедневно что-то бэкапить, работают они круглосуточно, их можно просто по времени развести, ночь длинная))) А вот если в начале рабочего дня всё бэкапить - то нужно будет создвать два задания. Одно - запаковать результаты предыдущего рабочего дня. Второе - залить на сервер. И их уже балансировать вручную. Что при большом объеме хостов несколько геморно.

#9

slant писал(а): ↑
16 июл 2023, 21:03
...или тупо аккаунт отберут.

Вот стоит выразить мысли письменно, и ситуация сразу становится яснее. Ну его, этот Яндекс. Цена вопроса - плюс-минус тыща, и то не моя, а конторская, а если мне главную учетку заблочат за нарушение использования сервиса, то будет вообще задница. Спасибо за беседу и за подсказки!
ogankvik, а сколько хостов с виндой нужно бэкапить, если не секрет?

ogankvik · #10

Ара Магеддон писал(а): ↑
16 июл 2023, 20:40
1. На сервере бэкапов с линуксом поднять SFTP (входит в состав SSH). Можно и просто FTP, если сетка доверенная и в ней не водится всяких кулхацкеров.

Есть. ФСБшники

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

slant писал(а): ↑
16 июл 2023, 21:03
Которого у меня разумеется нету и быть не может (другая страна). Без предупреждения, внезапно.

А где вы сейчас, если не секрет?

Ара Магеддон писал(а): ↑
16 июл 2023, 21:11
ogankvik, а сколько хостов с виндой нужно бэкапить, если не секрет?

Около 10 серверов и несколько десятков пользовательских ПК с ценными данными.

#11

ogankvik писал(а): ↑
16 июл 2023, 21:51
А где вы сейчас, если не секрет?

Украина. Но яндекс это учудил еще в 2018-ом или 2019-ом. До ковида было дело.

#12

ogankvik писал(а): ↑
16 июл 2023, 21:51
Около 10 серверов и несколько десятков пользовательских ПК с ценными данными.

Тогда сюда уже просится что-то специализированное и с централизованным управлением, имхо.

#13

slant писал(а): ↑
16 июл 2023, 20:54
но она умеет в версионность (причем с разными стратегиями хранения/удаления) и однонаправленную передачу, так что для бекапа тоже может служить.

Мало того, так ещё и может синхронизировать конкретную папку с назначенной в настройках папки скоростью. То есть сеть не должна просесть очень сильно при большом числе синхронизируемых файлов/папок.
Но, по большому счёту, должна быть какая-то документально оформленная стратегия резервного копирования: что, когда, куда, в каком объёме, каким образом. Без этого администратор будет постоянным мальчиком для биться: например, пользователь за 5 минут три раза изменит файл, а потом будет предъявлять претензии, что администратор не обеспечил резервирование, допустим, самого первого варианта до внесения всех последующих изменений.
У меня имелось несколько серверов на Windows, поэтому подобная задача решалась довольно-таки просто встроенными возможностями Windows Server. А так – действительно следовало бы подумать

slant писал(а): ↑
16 июл 2023, 20:54
чтобы использовать полноценную клиент-серверную систему резервного копирования, с агентами в винде.

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

Ара Магеддон писал(а): ↑
16 июл 2023, 20:40
Можно создать каждому юзеру отдельный SFTP-аккаунт (не равно аккаунту пользователя linux), чтобы он заливал файлы только в свою папку на сервере...
Сложность настройки сервера.

А зачем каждому пользователю свой аккаунт? Это если исходим из параноидального отношения к безопасности и предположения того, что, во-первых, пользователь умеет работать с командами rclone, а во-вторых – имеет доступ к файлу настроек rclone.conf Если предотвратить во-вторых, то можно ограничиться одним аккаунтом, но при создании архивов tar в имени архива добавлять имя компьютера или пользователя сети.

slant писал(а): ↑
16 июл 2023, 21:03
... потребовали войти через привязанный телефонный номер

Да у меня вообще сложилось впечатление, что у mail.ru паранойя стала рулить. C периодичностью раз в месяц-два начинаю получать сообщения, что подозревается попытка взлома. Возможно, это может быть объяснено тем, что использую Облако.Mail.Ru через rclone, но с разных компьютеров. А при смене пароля аккаунта Mail.Ru существующий пароль rclone для внешних приложений cбрасывается и нужно генерить новый. А после этого ещё и вносить изменения в rclone.conf Бесит страшно, но никуда пока не денусь: за 3 бесплатных аккаунта по 1 ТБ облака жаба душит.

#14

madesta писал(а): ↑
17 июл 2023, 02:46
Это если исходим из параноидального отношения к безопасности и предположения того, что, во-первых, пользователь умеет работать с командами rclone, а во-вторых – имеет доступ к файлу настроек rclone.conf

А в rclone.conf ещё и пароль на FTP не хранится. А где он хранится - хрен знает))) У меня несколько иная ситуация: на каждой машине установлен Anydesk с доступом по паролю, который знает больше одного человека. Решил вот компенсировать потенциальную уязвимость отдельного хоста хотя бы мерами по сохранности бэкапов.

useful · #15

Для бесплатного использования системы резервного копирования RuBackup доступна лицензия, позволяющая выполнять резервное копирование и восстановление суммарным объемом резервных копий не более 1Тб. Эта лицензия включена в серверный пакет RuBackup.
https://www.rubackup.ru/index.php/try
https://www.rubackup.ru/docs/1.9/RuBack ... indows.pdf

#16

Ара Магеддон писал(а): ↑
17 июл 2023, 06:55
А в rclone.conf ещё и пароль на FTP не хранится. А где он хранится - хрен знает)))

Пароли на ftp + пароли для доступа к сетевым папкам локальной сети, узлам SSH и т.д. и т.п. расположены в файле ~/.local/share/keyrings/Связка_ключей_по_умолчанию_keyring
Ниже приводится пример части содержащейся в данном файле информации. Срока secret= и является паролем. Естественно, что в примере указаны "липовые" данные:

[1]
item-type=1
display-name=travis@h-5.net.org
secret=traverse93
mtime=1562794223
ctime=1562794223

[1:attribute0]
name=protocol
type=string
value=ftp

[1:attribute1]
name=server
type=string
value=h-5.net.org

useful писал(а): ↑
17 июл 2023, 07:21
суммарным объемом резервных копий не более 1Тб.

Смущает этот пункт:
6.8. Компания гарантирует, что поставленное ПО будет по существу соответствовать пользовательской документации в течение 90 (девяноста) дней с момента предоставления Лицензии, в том случае, если ПО используется в соответствии с пользовательской документацией.
Заявление суммарным объемом резервных копий не более 1Тб не отражает конкретику. Как считается 1 ТБ: за всё время использования, за сеанс, за день и т.п.? И когда скачивается отсюда, то с какой лицензией скачивается? А получится типа "пробного периода". И какому типу лицензия на 1 TБ соответствует из этого списка?
Ну и для работы системы требуется СУБД PostgreSQL. Тоже вопросик: какой версии (от или не выше)?
Формулировки в описаниях должны быть такими, которые не вызывают двоякого толкования содержания этих формулировок. А то выходит "Закон – что дышло: куда повернул, туда и вышло".

useful · #17

madesta писал(а): ↑
17 июл 2023, 07:42
Смущает этот пункт:

А меня смущает

ogankvik писал(а): ↑
16 июл 2023, 21:51
Около 10 серверов и несколько десятков пользовательских ПК с ценными данными.

При таком парке не иметь финансирования на организацию проф. бэкапа немного смешно.
За сорок лет в айти я много проф праздников в свою копилку добавил.
День медика тоже своим считаю, т.е. прекрасно понимаю как там деньги добываются.
p.s. Может конечно автор темы уже не с медиками, но в любом случае не понимаю, как это возможно, при таком парке только сейчас задумываться о бэкапах на коленках.
p.p.s. Выше уже рекомендовали http://www.opennet.ru/soft/Short_Doc_Bacula.pdf

#18

useful писал(а): ↑
17 июл 2023, 08:46
При таком парке не иметь финансирования на организацию проф. бэкапа немного смешно.

Так автор, вероятно, как-то втихую хочет решить этот вопрос. Но нюанс в том, что при отсутствии профессионального решения, а соответственно и пакета сопутствующих документов (а ещё лучше плюсом и сопровождающего ПО вендора), при малейшей порче или пропаже данных он останется крайним. И хорошо ещё если ущерб будет выражаться во времени простоя, а не в безвозвратной потере каких-либо очень важных медицинских данных. Мне тоже как-то странно слышать, что до сих пор процедуры бэкапа не разработаны. На мой взгляд, это является одной из первоочерёднейших задач не только в медицине, но и в любой другой области. Как говорится, много резервных копий не бывает и в идеале лучше делать избыточное (двойное или тройное) резервирование, чем потом кусать себе локти.

Кто сейчас на конференции