Инкрементальный бэкап

Приветствую Вас, уважаемые коллеги и участники форума.
Имеется такая задача: необходимо организовать инкрементный бэкап таким образом, чтобы копировались только измененные и новые файлы, при этом не удалялись старые файлы.
Т.е. если копируется измененный файл, то его прежняя версия должна продолжать храниться в бэкапе.
Также, если в источнике удалился какой либо файл и/или папка то в бэкапе это не должно удалиться.
Собственно вопрос: каким образом это сделать? Решение должно быть преимущественно бесплатным.

0

Сообщение от Maks запускается батник от имени админа

и в батнике текстом прописаны логин и пароль? Опасно так голым задом подставляться, надежнее когда сервер сам копию забирает...
Ну а впрочем некое решение задачи тс найдено, тему можно больше не тревожить.

0

Сообщение от alexboyka и в батнике текстом прописаны логин и пароль? Опасно так голым задом подставляться

И чем же это опасно?
Батник недоступен для чтения обычным пользователем, срабатывает от имени администратора и лежит в директории, куда путь пользователю закрыт.
На сервере "шара" открывается только на момент копирования бэкапов. У ранее созданных бэкапов, на том же сервере, отбираются права для этого самого пользователя, который прописан в батнике. Можно, также, и вовсе копировать бэкапы внутри сервера в недоступную от локальной сети область. Для каждого ПК своя шара и свой пользователь, соответственно. А хранение паролей в батнике намного надежнее, чем сохраненные пароли в системе, ведь тот же троян и любой другой червь не будет проверять все батники, на предмет наличия учетных данных.

Сообщение от alexboyka надежнее когда сервер сам копию забирает

Чем это надежнее?

0

Сообщение от Maks Чем это надежнее?

Присоединяюсь к alexboyka, выполнение резервного копирование на стороне независимого сервера - это одна из основных best practices.

Например, злоумышленник (вирус-шифровальщик) смог повысить свои полномочия в системе (privilege-escalation vulnerability) и тогда у него появляется полный доступ не только к локальной системе, но и к хранилищу с резервными копиями. В этом случае резервные копии могут быть уничтожены или зашифрованы.

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

В случае независимого/внешнего сервера, выполняющего задания, резервные копии останутся недоступными.

1

Сообщение от KDE777 Например, злоумышленник (вирус-шифровальщик) смог повысить свои полномочия в системе (privilege-escalation vulnerability) и тогда у него появляется полный доступ не только к локальной системе, но и к хранилищу с резервными копиями. В этом случае резервные копии могут быть уничтожены или зашифрованы.

Интересно, каким образом, если у сетевого пользователя нет прав на вчерашние и более ранние бэкапы (icacls), либо бэкапы перемещены в другую директорию сервера?

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

В этом случае, если сервер сам будет собирать данные, он также выгребет эти данные к себе, так что это не мера.

Сообщение от KDE777 В случае независимого/внешнего сервера, выполняющего задания, резервные копии останутся недоступными.

Они и так останутся недоступными.
А вот выставлять пользовательские ПК шарой в сеть не комильфо.

0

Сообщение от Maks Интересно, каким образом, если у сетевого пользователя нет прав на вчерашние и более поздние бэкапы (icacls), либо бэкапы перемещены в другую директорию сервера?

Сообщение от KDE777 А ещё возможна более незаметная/изощренная атака - модификация самого задания.

Сообщение от Maks В этом случае, если сервер сам будет собирать данные, он также выгребет эти данные к себе, так что это не мера.

В случае задания на независимом сервере - если часть данных не попала в бэкап, сработает предупреждение.

1

Сообщение от KDE777 В случае задания на независимом сервере - если часть данных не попала в бэкап, сработает предупреждение.

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

0

Сообщение от Maks В случае задания на пользовательском ПК, в процессе создания бэкапа создается лог-файл, который также копируется на сервер.

Если система скомпрометирована, то в этот лог злоумышленник напишет что угодно.

Считаетe, что хранить пароль в текстовом файле и выполнять задание на стороне хоста с данными хорошая идея - ваше право. Я просто поделился своим опытом и общепринятыми рекомендациями.

И кстати, об опыте - именно отдельная система резервного копирования, однажды спасла рабочую БД, когда обиженный DBA, посреди рабочего дня снёс ERP-базу компании. У него были все права на SQL-сервере, но про независимые резервные копии, выполняющиеся каждые 30 минут он даже не знал

0

Сообщение от KDE777 И кстати, об опыте - именно отдельная система резервного копирования, однажды спасла рабочую БД, когда обиженный DBA, посреди рабочего дня снёс ERP-базу компании. У него были все права на SQL-сервере, но про независимые резервные копии, выполняющиеся каждые 30 минут он даже не знал

Для SQL это обычное дело. У меня скульные БД сидят на сервере, юзеры цепляются клиентскими 1С к БД по сетке.

0

Сообщение от Maks Для SQL это обычное дело.

Что именно обычное дело? Я вам описал пример, когда у DBA (Database administrator), как раз был полный доступ к SQL серверу, но задания на отдельном сервере не позволили ему добиться задуманного...

1

Сообщение от KDE777 Если система скомпрометирована, то в этот лог злоумышленник напишет что угодно.

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

Сообщение от KDE777 но задания на отдельном сервере не позволили ему добиться задуманного...

У меня закрался один вопрос: как Вам удается копировать активную базу, к которой подключены пользователи?

Сообщение от KDE777 когда обиженный DBA, посреди рабочего дня снёс ERP-базу компании.

Уголовное дело, однако.

0

Сообщение от Maks как Вам удается копировать активную базу, к которой подключены пользователи?

Вы про механизм VSS в ОС Windows что-нибудь слышали? А так же про дополнительные writer'ы для этой системы, в данном случае - Модуль записи SQL

Добавлено через 5 минут

Сообщение от Maks приходится использовать стороннюю программу, у которой есть функция уведомлений на электронную почту

Всё уже есть в самом Windows - Send-MailMessage

Кстати, как и для того, чтобы открытым текстом не хранить пароли - Quickly and securely storing your credentials

Сообщение от Maks о стороны сервера, после завершения всех бэкапов, шара закрывается, на действующих бэкапов отбираются права у сетевых пользователей, далее, эти бэкапы копируются (не перемещаются, а именно копируются) еще на несколько носителей. На следующий день все повторяется.

Вот ещё и из-за того, чтобы не заниматься подобным балетом, удобно использовать отдельный бэкап-сервер

1

Сообщение от KDE777 Всё уже есть в самом Windows

Вы не поняли, сам софт отправляет уведомления, в котором "говорит" о том, что скопировалось, а что нет.
Использование встроенного в Windows почтового агента при использовании сторорннего по для бэкапов этого не делать.

Сообщение от KDE777 Кстати, как и для того, чтобы открытым текстом не хранить пароли - Quickly and securely storing your credentials

Спасибо, обязательно ознакомлюсь, но чуть позже.

Сообщение от KDE777 Вот ещё и из-за того, чтобы не заниматься подобным балетом, удобно использовать отдельный бэкап-сервер

Это палка о двух концах, поэтому, с Вашего позволения, я останусь при своем мнении.

Добавлено через 5 часов 37 минут

0

0

0

Сообщение от Maks на аппаратной платформе крутятся несколько виртуальных серверов, так вот если мне планировать сбор бэкапов с сервера

В этом сценарии ещё важнее продумать грамотное резервное копирование, иначе выход из строя одной железки, сразу лишит всю конторку ИТ-инфраструктуры

Сообщение от Maks для этого самого сервера придется выделять больше ресурсов, в ущерб другим сервисам

Задача ИТ/ИБ отдела предоставить бизнесу информацию:

1. какие есть риски (и их вероятность) потери данных:

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

2. для каждого риска предоставить возможные варианты резервирования

3. для каждого варианта резервирования предоставить:

- цену реализации (лицензии, железо, зп доп сотрудников, обслуживание, снижение производительности...)
- длительность простоя, при восстановление этим вариантом

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

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

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

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

1

Сообщение от KDE777 В этом сценарии ещё важнее продумать грамотное резервное копирование, иначе выход из строя одной железки, сразу лишит всю конторку ИТ-инфраструктуры

Я всегда это учитываю, причем, стараюсь разместить железки территориально в разных местах.

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

Приятно встретить человека компетентного, я придерживаюсь той же стратегии.

Сообщение от KDE777 И тогда вас не будут волновать - не только снижение производительности, из-за выбранного подешевле варианта, но и полное отключение всех пользователей от ИС, например на 2 часа, для проведения регламентного обслуживания

Меня это вообще не волнует.
Есть Заказчик, который готов выделить определенную сумму денег.
Из нее и пляшем.
Само собой, все озвучивается и аргументируется.
Но, некоторый директорат, привык действовать на "авось", засим и получаем малопроизводительную ИС и скудное финансирование.
А регламентное обслуживание, я стараюсь проводить вне рабочее время, ну как-то так привык, ведь в этом случае есть запас времени на устранение непредвиденных обстоятельств (это бывает крайне редко, но все же)..

0

Сообщение от Maks Есть Заказчик, который готов выделить определенную сумму денег. Из нее и пляшем.

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

1

Сообщение от KDE777 Ну вот и выяснили, что у вас нет отдельного сервера для резервного копирования, не из-за сомнений в необходимости - "Чем это надежнее?", а из-за отсутствия денег у заказчика

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

0