Comments 17
Берём (покупаем!) WinRar. изучаем файл ключей. он небольшой и русскоязычный (для толпы мужиков «за 60» — это важно — они могут быть доки в сопромате и какой-нибудь гидродинамике, но IТ-английский для них взаправду боль).
прописываем cmd-файл что-то вида
winrar a @файл-список куда
ключиками ему пишем «архивировать с полными путями», «открытые для записи», «добавлять к имени архива дату», и, например, «с датой изменения не старше недели»
и запускаем хоть раз в час и/или по расписанию.
лучше ещё задать простой пароль типа 111 — просто что бы антивирусы не парсили каждый раз.
Далёкому от софта технарю это дело освоить и наладить как надо со всеми подвохами хитрыми — день, ещё неделю в голове подержать. что бы разные варианты предусмотреть.
(напр список файлов с именем (датой) архива в отдельный текстовый файл дописывать — что бы потом не рыться по архивам где оно лежит)
Для конструкторов и дизайнеров — самое оно — всегда можно выудить за любую дату промежуточные файлы.
Хотя лучше всё же все простые (офисные) и «тяжелые» по разным архивам распихивать. лучше даже каждый со своим расписанием.
Решал в точности эту задачу силами технарей без админа — но мне важнее было физически бэкап с территории надёжно вынести ввиду кучи разных обстоятельств.
прописываем cmd-файл что-то вида
winrar a @файл-список куда
ключиками ему пишем «архивировать с полными путями», «открытые для записи», «добавлять к имени архива дату», и, например, «с датой изменения не старше недели»
и запускаем хоть раз в час и/или по расписанию.
лучше ещё задать простой пароль типа 111 — просто что бы антивирусы не парсили каждый раз.
Далёкому от софта технарю это дело освоить и наладить как надо со всеми подвохами хитрыми — день, ещё неделю в голове подержать. что бы разные варианты предусмотреть.
(напр список файлов с именем (датой) архива в отдельный текстовый файл дописывать — что бы потом не рыться по архивам где оно лежит)
Для конструкторов и дизайнеров — самое оно — всегда можно выудить за любую дату промежуточные файлы.
Хотя лучше всё же все простые (офисные) и «тяжелые» по разным архивам распихивать. лучше даже каждый со своим расписанием.
Решал в точности эту задачу силами технарей без админа — но мне важнее было физически бэкап с территории надёжно вынести ввиду кучи разных обстоятельств.
Большинство бесплатных бекап-утилит как раз и работает по этому принципу. Берем хрен знает что, копируем хрен знает куда, и ищем хрен знает как. В реальности все выглядит более грустно.
1. Ошибки доступности источника (источников) — ошибки на харде, недоступен сетевой ресурс, недопустимая длина в имени и.т.д.
2. Ошибки получателя — добавим внезапно закончившееся место
3. Непонятно как искать, как хранить заданное n копий файла, как рассчитать требуемое место для следующего бекапа.
И при этом возникает вопрос обработки ошибок, ведения логов, рассылки уведомлений, тестирования архивов. Что в итоге со временем приводит к невозможности восстановления и потере данных.
Нет, для небольших задач оно применимо, но при дальнейшем росте становится немасштабируемо.
Все это относится как к вашему примеру, так и к самой статье.
1. Ошибки доступности источника (источников) — ошибки на харде, недоступен сетевой ресурс, недопустимая длина в имени и.т.д.
2. Ошибки получателя — добавим внезапно закончившееся место
3. Непонятно как искать, как хранить заданное n копий файла, как рассчитать требуемое место для следующего бекапа.
И при этом возникает вопрос обработки ошибок, ведения логов, рассылки уведомлений, тестирования архивов. Что в итоге со временем приводит к невозможности восстановления и потере данных.
Нет, для небольших задач оно применимо, но при дальнейшем росте становится немасштабируемо.
Все это относится как к вашему примеру, так и к самой статье.
Сразу по всем 3 пунктам, я делал так — вывод в stderr перенаправляется в файл, если утилита вернула что-то отличное от 0, то содержимое рассылается по почте ответственным, сама ОС контролирует успешность операций копирования и т.п.
Off: На самом деле кипишь не об этом. Офисному работнику системы контроля версий не под силу. Даже от конструкторов слышал, что две кнопки "ОК" и "Отмена" — это слишком сложно. (Поскипал много эмоционального текста)
Офисному работнику, имхо, об этом знать вообще не обязательно. Так что две кнопки — это многовато ;) Есть же планировщик.
Но и я немного о другом. Вот стоит любая система бекапа, в хранилище копируют бекапы три десятка пользователей и в один момент места на дисках не хватает. Если мы имеем распределенную систему с агентами копирования — то о такой ситуации мы узнаем только по факту. Если же мы делаем бекапы общедоступных ресурсов силами сервера — можно посчитать заранее, сколько потребуется места и предупредить об этом.
Пример: в 17.00 все ушли, в 19.00 запускается бекап по расписанию. А дальше два варианта: если место посчитано заранее — о нехватке мы узнаем этим же вечером. Если нет — то только по окончании копирования, не исключено что завтра утром.
Другой пример: Бухгалтерии не требуются копии документов, поскольку часто они все связаны между собой. Проще откатить все данные на сутки. Система контроля версий им не нужна. А диспетчер вносит изменения в оперативные схемы и ему может портебоваться несколько версий одного документа. Система бекапа этого не предусматривает — копаем кучу файлов ручками. Предусматривает — можем заранее сказать в какие дни были сделаны копии.
Алерты тоже хорошо, что шлются, но есть же важность у каждого. Где-то не сохранился один файл и тьфу на него, а где-то возникла ошибка запуска. В моем случае все это попадает (должно попадать) в zabbix, который уже сам сортирует, стоит меня будить ночью или доживет до утра.
Вы автоматизировали свою работу — молодец, уважаю. Сам иногда пишу велосипеды и костыли для своих задач. Но таких решений, имхо, достаточно и все они достаточно специфичны. Чтобы сделать ваше решение универсальным — его еще пилить и пилить.
Но и я немного о другом. Вот стоит любая система бекапа, в хранилище копируют бекапы три десятка пользователей и в один момент места на дисках не хватает. Если мы имеем распределенную систему с агентами копирования — то о такой ситуации мы узнаем только по факту. Если же мы делаем бекапы общедоступных ресурсов силами сервера — можно посчитать заранее, сколько потребуется места и предупредить об этом.
Пример: в 17.00 все ушли, в 19.00 запускается бекап по расписанию. А дальше два варианта: если место посчитано заранее — о нехватке мы узнаем этим же вечером. Если нет — то только по окончании копирования, не исключено что завтра утром.
Другой пример: Бухгалтерии не требуются копии документов, поскольку часто они все связаны между собой. Проще откатить все данные на сутки. Система контроля версий им не нужна. А диспетчер вносит изменения в оперативные схемы и ему может портебоваться несколько версий одного документа. Система бекапа этого не предусматривает — копаем кучу файлов ручками. Предусматривает — можем заранее сказать в какие дни были сделаны копии.
Алерты тоже хорошо, что шлются, но есть же важность у каждого. Где-то не сохранился один файл и тьфу на него, а где-то возникла ошибка запуска. В моем случае все это попадает (должно попадать) в zabbix, который уже сам сортирует, стоит меня будить ночью или доживет до утра.
Вы автоматизировали свою работу — молодец, уважаю. Сам иногда пишу велосипеды и костыли для своих задач. Но таких решений, имхо, достаточно и все они достаточно специфичны. Чтобы сделать ваше решение универсальным — его еще пилить и пилить.
(покупаем!) WinRar
Рошаль перелогиньтесь.
Поздравляю, вы изобрели историю файлов Windows. :)
Я пользуюсь Duply под nix и Duplicati под винду.
Хотел бы поделиться следующим решением, которое внедрил лет 5 назад для компании, где много людей с Solidworks работает и AutoCAD. Не изящное, конечно, но работает (прошу не минусить) :)
Итак, сервер Linux и общий каталог, подключенный по SMB. Структура \\backup\$username\$uniq_id{1,2,3...99} — $uniq_id — это идентификатор 32 символьный. Пользователь в любой каталог копирует нужное содержимое + в каталоге $uniq_id\td создаёт текстовый файл с определенным содержимым типа «key=value». Там значения сколько хранить, простое описание. Ну а дальше — по ночам осуществляется обработка с помощью sh-скрипта, что называется «парсятся файлы» :) — создаётся запись в СУБД, а сам архив переноситься в более надёжную (и более медленную) систему хранения. Утром приходит на почту пользователю письмо с описанием — какие задания были выполнены, сколько срок хранения и URL — что нужно вбить в браузере для восстановления. Когда нужно восстановить: достаточно переход по URL осуществить и, в зависимости от нагрузки на сервера, файл будет скопирован (с помощью rsync, который в фоне запускается раз в несколько минут и копирует из списка все, что указано) в \\backup\restore\$uniq_id
Итак, сервер Linux и общий каталог, подключенный по SMB. Структура \\backup\$username\$uniq_id{1,2,3...99} — $uniq_id — это идентификатор 32 символьный. Пользователь в любой каталог копирует нужное содержимое + в каталоге $uniq_id\td создаёт текстовый файл с определенным содержимым типа «key=value». Там значения сколько хранить, простое описание. Ну а дальше — по ночам осуществляется обработка с помощью sh-скрипта, что называется «парсятся файлы» :) — создаётся запись в СУБД, а сам архив переноситься в более надёжную (и более медленную) систему хранения. Утром приходит на почту пользователю письмо с описанием — какие задания были выполнены, сколько срок хранения и URL — что нужно вбить в браузере для восстановления. Когда нужно восстановить: достаточно переход по URL осуществить и, в зависимости от нагрузки на сервера, файл будет скопирован (с помощью rsync, который в фоне запускается раз в несколько минут и копирует из списка все, что указано) в \\backup\restore\$uniq_id
Хранение копий бинарных файлов быстро выжрет место или история будет короткой.
Важная часть систем бэкапирования — безопасная и быстрая передача файлов на другой сервер — не решена.
Мультиплатформенность отсутствует, как я понимаю, а это минус — на линуксах легче найти дешёвые стораджи.
Кстати как настроить распространенную схему бэкапов: «11 за прошлые месяцы + 3 за прошлые недели + 6 за прошлые дни + 23 за прошлые часы»?
Я бы рекомендовал присмотреться к Borg
Важная часть систем бэкапирования — безопасная и быстрая передача файлов на другой сервер — не решена.
Мультиплатформенность отсутствует, как я понимаю, а это минус — на линуксах легче найти дешёвые стораджи.
Кстати как настроить распространенную схему бэкапов: «11 за прошлые месяцы + 3 за прошлые недели + 6 за прошлые дни + 23 за прошлые часы»?
Я бы рекомендовал присмотреться к Borg
Видимо многие не поняли основной посыл статьи. Смысл — пользователю в конце рабочего дня кликнуть по скрипту и быть свободным. Не проблема вывести на экран окно с предупреждением в случае ошибок в процессе. Зачем пользователю линукс тут, не очень понятно. Если он в 1С данные забивает, то статья не про него.
Что может быть быстрее операции копирования файла? Хард вынуть?
Тут дедупликация может сильно помочь на самом деле. Мы как раз бинарные бекапы каждодневные для одной хитрой софтины снимаем, очень эффективно получается.
Уже почти 8 лет назад тоже писал программу для непрерывного резервного копирования. Статья на хабре: https://habrahabr.ru/post/75606/
Довольно долго пользовался ей и радовался жизни. А потом появилась история файлов Windows, которая полностью покрыла все потребности, и мой велосипед оказался не нужен. Теперь всё автоматически копируется на NAS в зашифрованную папку. А самое удобное, что управление интегрировано в обычный проводник. Плюс разные стратегии удаления старых версий (ограничение по времени, по размеру и пр.).
Довольно долго пользовался ей и радовался жизни. А потом появилась история файлов Windows, которая полностью покрыла все потребности, и мой велосипед оказался не нужен. Теперь всё автоматически копируется на NAS в зашифрованную папку. А самое удобное, что управление интегрировано в обычный проводник. Плюс разные стратегии удаления старых версий (ограничение по времени, по размеру и пр.).
Хардкор, но труъ:
unix + samba + zfs.
Ежедневные снапшоты (да хоть ежеминутные) не нагружают фс с её парадигмой копи-он-райт.
В случае чего, снапшот монтируется отдельной шарой, не мешая никому.
unix + samba + zfs.
Ежедневные снапшоты (да хоть ежеминутные) не нагружают фс с её парадигмой копи-он-райт.
В случае чего, снапшот монтируется отдельной шарой, не мешая никому.
Sign up to leave a comment.
Вечерний backup. Делаем все проще и понятней