Комментарии 28
Дешево? Да. Без лишних затрат - не сказал бы. Все может рухнуть в тот момент когда что-то слетит и понадобятся резервные копии. А дальше выяснится что их нет. Такая вещь как архивация требует ставить проверки везде где только можно. Я за 14 лет работы системным администратором на всякое насмотрелся. По вашему скрипту - проверяйте результаты выполнения команд. (при этом xcopy/robocopy часто возвращают 0 даже если файл не скопирован, особенно при копировании на сетевую шару). Проверяйте размеры файлов(не просто, что он больше нуля) и контрольные суммы. Проверяйте наличие свободного места на диске. Удаляйте старые копии только если новые скопированы успешно. Используйте нестандартные расширения для имен архивов(частично убережет вас от шифровальщиков). Архивируйте в несколько хранилищ. Выбирайте надежные и быстрые протоколы при копирования по сети. Следите за тем чтобы ваши скрипты не мог дописать злоумышленник....
И дополнительно - неплохо бы проверять, что из созданной копии можно что-то вменяемое извлечь.
Возможно. Тут скорее помимо создания и реализации плана по архивации, нужен план по восстановлению и его проверка. Теоретически, если архиватор не выдал ошибок при архивации(тот же 7zip или tar предупреждают когда архивируемый файл начал кто-то перезаписывать в процессе архивации), и мы удостоверились что файл помещенный в хранилище байт в байт совпадает с локальным, то вероятность что архив можно будет распаковать будет очень велика.
Я бы сказал, что не помимо, а в первую очередь нужен план по восстановлению, включающий в себя проверку работающего восстановления из бекапа. А план бекапа нужен лишь, как обеспечивающий возможность этого восстановления.
В конце-концов, никого не будет интересовать, как там что бекапилось.
Это я говорю, как человек, у которого на заре карьеры в нужный момент выяснилось, что бекап красиво работал, но неделю не создавал восстанавливаемые копии...
Как показывает опыт, наиболее часто теряемая и повреждаемая информация (которая иногда оказывается к тому же достаточно критичной) располагается не на сервере, а на рабочих столах (угу, даже не в папке Документы) компьютеров пользователей... особенно когда
бюджетное учреждение, скромные зарплаты, старенькая техника, запланированного бюджета на ИТ нет совсем
Я обычно стараюсь согласовать с топовым вменяемым руководством памятку содержания: "сисадмины не отвечают за содержимое на С, D, $desktop%, %mudocu%/. Храните инфу на сетевых дисках Х,Y,Z". И тогда просто говоришь: "Ну сам буратино, мы ж предупреждали". В начале карьеры, спасало от непробиваемых юзеров, которые не доверяли компам и всю свою работу хранили на одной noname флешке. А потом вопили на всех, что она, от ваших компов, навернулась.
Ну если по-правильному, то должен существовать некий документ типа "Правила использования компьютерной техники в организации", за ознакомление с которым каждый, работающий с компом, должен ознакамливаться под подпись, и в котором все очевидные вещи типа "документы хранятся только на сервере" подробно расписаны. Но увы - все плюют ядовитой слюной на такой документ, даже если он есть, и даже если за ознакомление подписались... а понимающее руководство, которое по факту обнаружения нарушения выпишет нарушителю звездюлей на сумму месячной премии - это фантастика.
вот и выросло поколение, которое даже не подозревает про ленты и offline хранение бэкапов
Давайте будем откровенны, ленты - дорого. В свое время (это было 3-4 года назад), для 1 Тб данных у меня вышло что-то около 200к. Не считая ручного труда по замене кассет и проблем с их хранением (сейф, другое помещение и пр.).
А вот оффлайн, да, с этим попроще, чем кстати и воспользовался. Удаленная площадка, "PLC" который включал корзину по SNMP и, после завершения бэкапа, отключал ее от питания. Но это было прям совсем решение для бедных, сейчас бы выбивал какой-ндь простейший Synology с WoL.
Ленты когда-то были, но хранение на обычном жестком диске, в настоящий момент самый дешевый вариант, когда общий размер важных копий не превышает 2 терабайта. Что и используется.
Microsoft JScript...
robocopy ...
2022 год, 13 лет как Powershell идет в составе ОС Windows...
В Server 2012 уже был Windows Image Backup, который из коробки умеет бэкапиться в шару и слать уведомления, работать с shadow copy и еще много чего в том числе ротацию и проверку...
Если в системе данная утилита отсутствует, то нужно установить Microsoft Resource Kit 2003.
Если у вас до сих пор стоит 2003 сервер, то, боюсь, бэкапы это меньшая из ваших проблем. Ребят, так то системе 20 лет скоро, я конечно понимаю, что совершенство не нуждается в изменениях, но... блин, серьезно 2003?
Нет, 2003 конечно не используется, но "ноги" растут примерно с тех времен.
Естественно были попытки снимать копии встроенным средством, но по разным причинам это оказалось менее удобно, чем "самописный" скрипт.
Я прекрасно понимаю слишком сильную простоту реализации, в которую можно добавить кучу возможностей, но во главу угла здесь ставилось возможность доступа к данным этого бэкапа лишь с помощью архиватора, с любого рабочего места. Открыл, достал файл, закрыл.
Приведенный здесь вариант не конечная итерация этой "поделки". Сейчас это немного более сложное средство, с разностным копированием и более сильным контролем. Частично реализованное на Python для работы и в Linux среде.
Первоначально скрипт был сделан, кстати, на PowerShell, но не понравился он по скорости работы и "монстрообразности" самого языка. Понимаю это вкусовщина, но PowerShell визуально некрасивый язык. CMD, VBS, JSCRIPT тоже не красавцы, но визуально в них быстрее поймешь что происходит.
Для подобных задач резервного копирования и автоматизации вообще, много лет использую бесплатную программу xStarter. Такое же резервирование и отправка по FTP на внешний сервер в xStarter-е делается примерно в двадцать строчек скрипта. И попробую предложить вариант команды удаления старых копий старше 5 дней в cmd "forfiles /p E:\BACKUP /m *.7z /s /d -5 /c "cmd /c del @file" "
Автор наверное забыл написать, что бэкапы баз SQL совершаются штатными средствами SQL ?!?: Ибо "копи-пастом" файлы баз сбэкапить "некомильфо" - за целостность (и доступность) никто не ручается. А насчет стратегии бэкапов - так это классика, самый последний по очереди бэкап должен лежать за 100500 километров от серверной.
Я в статье указал - что процедура снятия бэкапа - прерогатива сервера владельца данных. Скрипт уже забирает то, что сервер ему предложил в качестве копии. Естественно MS SQL снимается стандартными средствами и полученные *.bak файлы уже объединяются в один архив этим скриптом. Лезть архиватором к файлам работающей базы, было бы верхом глупости.
Лезть архиватором к файлам работающей базы, было бы верхом глупости.
Как обычно, не без исключений. Например, для резервирования базы Firebird проще и быстрее остановить процесс сервера и выполнить файловое копирование файла БД, чем заморачиваться на штатные средства изготовления бэкапа. Я уж не говорю об SQLite.
У меня такая же фигня с домашним резервированием. Стоит nas на него копируются файлы раз в период. Одни реже, другие чаще. Но есть проблема с сеткой. Точнее с WiFi. Гигабайты прокачиваются не очень то и быстро. Нужно оптимизировать. Но руки не доходят.
@arwa, а почему не рассматривали специализированные решения? Ну например тот же Urbackup - забирает бэкапы своим клиентом, может снимать образы дисков, умеет копировать БД при помощи ShadowCopy - решает все прочие проблемы, которые вы тут описываете. Есть веб-интерфейс, уведомления на почту и пр.
От себя добавлю, что неплохо показал себя подход - сервер бэкапов + локальные бэкапы на отдельный массив (или даже просто hdd), скрытый от системы при помощи встроенной системы бэкапов Windows. Насколько мне известно, пока нет известных случаев, когда бы шифровальщики добрались до таких скрытых томов. Но даже если это и случится - есть копия на сервере бэкапов.
Если у вас до 10 серверов, можно поставить veeam br comunity edition, он бесплатен.
Не, с точки зрения администрирования - это всё очень интересно, особенно это обсуждать. А с точки зрения "по жизни".... Блин, если админу нечем заняться. Всё это решил бы какой-нить Акронис в 5 кликов. Сколько он там сейчас стоит? 20 за сервер? А если это дорого, сколько админ поучает? Тех же 20? Так может проще в майкор пойти, или в деливери, там поболе, чем в майкоре.
Acrоnis конечно решил бы. Продукт хороший и рассматривался, даже коммерческие предложения запрашивались. Но итоговая цена на тот момент оказалось такая, что бюджет отдела съедала не подавившись.
Сейчас он бессрочный стоит почти 50 000 за сервер, 20 000 по подписке, т.е. или 500 000 за раз, до того как после очередных обновлений все перестанет работать и станет просить более свежую версию, или 200 000 выкладывать каждый год. Именно поэтому и было придумано такое решение, которое покрывало наши потребности на то время, на 90%.
Ну смотрите, 10 серверов. из них 1-2 сервера с БД, на них нужен сервер Акрониса безусловно, т.к. сделать снимок живой базы он может только с прямым доступом к файлам БД. Дальше надо думать, т.к. там у вас бэкап файлов. Если это не файлы ОС, то скорее всего можно придумать к ним монопольный доступ. К тому-же скрипт тоже не сможет снять бэкап без монопольного доступа(Акронис может, даже если файл не на самом сервере, но остаётся вопрос консистентности файла). К остальным файлам нужно просто дать Акронису доступ. И таким нехитрым движением 10 лицензий превращается в 3-4. То, что функционал будет несравним - нечего и говорить. И лицензию это никак не нарушает, насколько я понимаю.
Удалять копии бэкапов по условию "старше N дней" - очень плохая идея. А если рабочий сервер у тебя сломается на N+1 дней? Да первая же задача бэкапирования после восстановления сервера убьет все твои бэкапы!!! И не факт что к этому моменту твоя рабочая база успеет восстановиться.
Гораздо лучше сохранять бэкапы по количеству, например, сохраняем "последние 10 бэкапов". Если бэкапов больше 10, то самый старый удаляем. И еще хорошо привязать удаление бэкапов к успешному окончанию бэкапирования, т.е. если бэкап не состоялся - ничего из бэкапов не удаляем, удаление производим только если свежий бэкап состоялся.
Резервное копирование без лишних затрат