Комментарии 55
Уже есть утилита, которая делает инкрементальный бэкап на любые носители (в т.ч., облака, а также может передавать через ftp, scp, rsync): duplicity. Правда, не знаю, работает ли она под Windows, но уверен, что работает.
При этом в ней миллион настроек, что включать в архив, что исключать, какого размера делать тома, шифровать ли GPG, как часто пересоздавать полный архив, и так далее.
Я ей делаю копии в два разных места: на флешку 64 Гб, и внешний жесткий диск. Еще как минимум два production сервера у меня бэкапятся duplicity на Amazon S3. Уже несколько раз приходилось восстанавливать файлы недельной давности из инкрементального бэкапа. Все делается очень просто, в отличие от скрипта в статье, не придется вручную искать нужный архив и вручную извлекать содержимое.
Вопрос — я на работе хочу посмотреть последнюю версию файла из дома (например какой нибудь чертеж или расчет, который я редактировал х дней назад). Я знаю что я могу в моей версии скачать последний или любой после дня х инкрементный архив и взять его оттуда — он там точно будет, для открытия не нужно ничего кроме как залезть в хранилище и скачать файл архива. Почему именно это действие? Потому что я веду бухгалтерию и делаю подработки, и поэтому у меня всегда возникает нужда посмотреть последние версии Excel, Word и Autocad документов.
Что нужно сделать чтобы из архива Duplicati на моем рабочем месте извлечь аналогичные файлы? Ставить / разворачивать архив с Duplicati на работе просьба не предлагать — проблемы с админскими правами я еще могу обойти (портабельная версия), но следы работы этого программного обеспечения не скрыть, со всеми вытекающими.
Написано, что duplicati — это практически 1-в-1 порт duplicity. Значит, во-первых, можно напрямую работать с файлами — у duplicity структура довольно самоочевидная, можно разобраться и вручную, в каком архиве что лежит. Во-вторых, раз есть portable версия, можно с ее помощью вытащить файл из резервной копии.
Если запрещено в принципе запускать сторонний софт на рабочем компьютере, то остается лишь первый вариант, конечно. Но это уже не техническая проблема.
Консольная версия duplicati работает без проблем, командная строка для сохранения на сервер:
Duplicati.CommandLine.exe backup webdav://webdav.yandex.ru/backup/work «путь_к_каталогу_с_исходными_файлами» --use-ssl --auth-username=«username» --auth-password=«password» --backup-name=«work» --dbpath=".\db.sqlite" --encryption-module=«aes» --compression-module=«zip» --dblock-size=«50mb» --keep-time=«3M» --passphrase=«пароль_для_шифрования» --skip-files-larger-than=«2GB» --default-filters=«Windows» --exclude-files-attributes=«temporary» --disable-module=«console-password-input» --exclude=«desktop.ini» --symlink-policy=Follow
Медленно, но шифрует и заливает параллельно. Итог на сервере:
duplicati-20180607T064546Z.dlist.zip.aes
…
duplicati-b0c9ccd8e5e9149a5aee1bb77e340571e.dblock.zip.aes
…
duplicati-ifd6e5340f66d4f5f939d48228cc75e5e.dindex.zip.aes
Извлечь бытовыми методами из этого отдельные файлы невозможно, нужно применить средства duplicati, а именно:
1) найти нужный файл через команду find
Duplicati.CommandLine.exe find webdav://webdav.yandex.ru/backup/work * --use-ssl --use-ssl --auth-username=«username» --auth-password=«password» --backup-name=«work2» --dbpath=".\db.sqlite" --passphrase=«пароль_для_шифрования»
2) скачать его в выбранный каталог через команду restore:
Duplicati.CommandLine.exe restore webdav://webdav.yandex.ru/backup/work2 «путь_к_файлу_на_сервере» --restore-path=«путь_к_каталогу_куда скачать файл» --use-ssl --auth-username=«username» --auth-password=«password» --backup-name=«work2» --dbpath=".\db.sqlite" --passphrase=«пароль_для_шифрования»
При попытке получить обновление уже скачанной версии архива Duplicati начинает сливать все подряд, и то что уже имеется, и то что новое. Т.е. чтобы обновить 21 remote files/57 files need to be restored/Restored 6 новых файлов на 6/48 мегабайт будет сливаться 1 гигабайт данных. Как то не очень пригодно для бытового использования.
21 remote files are required to restore
Downloading file (49.95 МБ)…
57 files need to be restored (6.04 МБ)
Downloading file (49.98 МБ)…
3 files need to be restored (6.04 МБ)
Downloading file (49.93 МБ)…
Downloading file (49.99 МБ)…
Downloading file (49.91 МБ)…
…
Downloading file (49.95 МБ)…
…
Downloading file (49.91 МБ)…
Downloading file (21.99 МБ)…
Downloading file (28.58 МБ)…
Downloading file (3.06 МБ)…
…
Verifying restored files…
Restored 6 (46.88 МБ) files to D:\…
Обычный рабочий или бытовой компьютер с ограниченной учетной записью, windows xp-7-10 Home Edition
2) Не требует прав администратора? — требует, и еще как требует.
3) Легко и быстро позволяет создавать резервные копии? наверное, не проверял, наверное потому что требования пунктов 1 и 2 отбивают охоту к проверке.
4) Unix way? — ага, «You need to have a configured backup job in True Image graphical user interface (GUI) before you can run it from command line.»
5) Использование любых хранилищ? Вы можете выбрать любое хранилище из тех, которые создал сам Acronis, что будет учтено в Ваших платежах за использование.
Вывод — честное бытовое использование вызывает сомнения в силу платности и ограниченности, ну а за деньги и при корпоративном применении — почему нет?
К тому же всякие 7z/rar просто несправляются когда очень-очень много мелких файлов. Пробовал как то, сделать архив моего диска с проектами WinRar показывает около 2 суток даже при минимальной компрессии. А вот платные программы бэкапов справляются с этим куда быстрее, всего часа за три.
Взамен могу предложить свои пунктики по поводу Вашего решения:
1) Имеет поддержку? — нет, автор один, его компетентность не подтверждена…
2) Не требует повышенного внимания? — требует, и ещё как требует
3) Легко и быстро позволяет создавать резервные копии? наверное, не проверял, наверное потому что требования пунктов 1 и 2 отбивают охоту к проверке.
4) Кроссплатформенно из коробки? — ага, «легко можно переписать примерно на 100 других вариантов командных оболочек»
Вывод — честное бытовое использование вызывает сомнения в силу сырости и ограниченности.
Вы предлагаете сохранить в открытом виде логин/пароль от учетной записи в которой у меня деньги лежат? И это не говоря уже про тот же пароль от архива в открытом виде в том же файле.
Эээ. Нет, спасибо.
И еще раз — это решение не для промышленных систем резервирования и защиты информации, это скорее бытовое применение, когда вероятность стащить у Вас пароль от хранилища примерно равна вероятности что у Вас стащат все остальные пароли и файлы вместе взятые. Если у Вас периодически взламывают компьютер и с него уходят в сеть все Ваши файлы и данные, а сам он становится хабом для дос-атак — Вам это решение точно не подойдет.
— Использование CMD.
— Используя скриптинг, Вы не используете ключи
— Не бэкапятся открытые файлы.
— Все сделанные бэкапы находятся в состоянии суперпозиции, они вроде и есть, но если не произведено тестовое восстановление, их как бы может и не быть.
— Отсутствует уведомление в почту/мессенджер о удачном/неудачном действе, ошибках в процессе.
— Отсутствие проверки доступности источника, временной папки и хранилища.
— «безопасность» через «упрятать»,«посолить», «вероятность»
— Отсутствие прогнозирования и проверки достаточности места на диске с временной папкой и в хранилище
— Бесконечные инкременты, пока руками на полный бэкап не тыкнешь.
— При создании нового полного бэкапа, Ваш скрипт сначала сносит все старые бэкапы, а только потом делает полный новый!
Список могу продолжать еще долго, но и этого уже с лихвой хватает, что бы не использовать данное решение. Смените язык программирования, почитайте про правило 3-2-1, почитайте про идеологию резервного копирования впринципе. Прокурите реализацию доставки файлов в облако через родной клиент облачного хранилища. Напишите свой бэкап клиент. Офигейте от трудозатрат. Бросьте это дело.
— Использование CMD — легко можно переписать примерно на 100 других вариантов командных оболочек;
— Используя скриптинг, Вы не используете ключи — вынести пути и так далее в ключи легко;
— Не бэкапятся открытые файлы — бекапятся. Не бекапятся только файлы, заблокированные на чтение. Через теневые копии (есть описание выше) можно и открытые и заблокированные файлы считать.
— Все сделанные бэкапы находятся в состоянии суперпозиции, они вроде и есть, но если не произведено тестовое восстановление, их как бы может и не быть — добавить в скрипт еще пару строчек на обратное скачивание и тестирование архива;
— Отсутствует уведомление в почту/мессенджер о удачном/неудачном действе, ошибках в процессе — добавить еще строчку с консольным mail — клиентом, реализующим данный функционал.
— Отсутствие проверки доступности источника, временной папки и хранилища — еще пару строк и еще немного данных для консольного mail клиента
— «безопасность» через «упрятать»,«посолить», «вероятность» — без комментариев, это вечное и реально проблемное место почти всех систем. unixforum.org/viewtopic.php?t=135935 для просто ознакомления, ну и решение — храните пароль в голове, вводите его в окошке.
— Отсутствие прогнозирования и проверки достаточности места на диске с временной папкой и в хранилище — увы, тут согласен
— Бесконечные инкременты, пока руками на полный бэкап не тыкнешь — отмечу, рабочие инкременты, которые мне и нужны. Я всегда знаю что в последнем инкременте лежит рабочий файл, если я с ним работал после создания полной версии бэкапа. В данном случае к примеру Duplicati ведет себя не лучше — бесполезно пытаться получить просто свежий файл, он всегда с сервера тянет полный бэкап;
— При создании нового полного бэкапа, Ваш скрипт сначала сносит все старые бэкапы, а только потом делает полный новый! — поменять строки местами, и сначала заказчивать тестировать, а потом сносить старый бэкап.
Таким образом, чтобы удовлетворить доброй половине Ваших желаний, всего лишь надо переписать скрипт с добавлением пары программ (использование теневых копий и консольного е-майл клиента), изменить порядок действий по проверке/удалению, и… бросить попытки курить трудозатраты на сложные системы, ибо овчинка выделки не стоит, ежедневную копию я уже имею, а отдельную копию на независимом носителе я и так делаю раз в две недели, что достаточно для домашнего использования.
И отмечу — скрипт можно использовать как пример логики, реализованной всего 2 программами. Расширить его можно всегда и любым способом. А курить родные клиенты облачного хранилища, или Duplicati с аналогами — поверьте, что курилось то курилось, список недостатков родных клиентов и программ «мы-вам-все-забекапим-по-феншую» будет еще длиннее чем указано у Вас по моему простенькому скрипту )))
Там не мои желания, там минимальный базис для любого скрипта резервного копирования, который можно раз настроить и забыть на пять лет. Дописать можно, я не спорю, но сейчас же этого нет. И строчки поменять, что бы логика правильно работала тоже можно, но изначально это опять же не реализовано. Уже сделано с ошибками из-за которых могут пострадать данные людей. А вся Ваша аргументация сводится к тому, что ну вот дописать всегда можно. Предлагаете сделать это сообществу? А смысл в статье тогда?
Ну я, возможно, понял бы если бы скрипт был жестью и адовым полотенцем, как делают немногие CMD-кодеры выкладывающие статьи сюда, но по факту ценность кода в статье нулевая. Просто потому что можно средствами архиватора делать фул и инкременты (напомню что атрибут «Архивный» именно для этого и существует), именовать файлы архивов по дате, а доставку в облако отдать клиенту облачного диска во имя секурности (некоторые из них уже сами умеют файло с локального диска перемещать в облако). Итого это одна строчка кода сразу забитая в таскшедулер. Я делал такую хрень (без облака) в 2002 году консольным винраром бэкапя базы 7.7 и дублируя нтбэкапом. Эта хрень даже до сих пор работает, не смотря на то что исходный 2003 сервак уже давно прошел через P2V процесс.
Не можете сами? Берете чужой скрипт, курите его логику, перелопачиваете код на свое усмотрение, добавляете своих перделок и собираете плюсы в сообществе. Некрасиво, но сойдет.
1. ставим новый диск
2. грузим Veeam recovery (с НАСа через PXE)
3. заливаем вчерашний образ на новый диск, перегружаемся.
4. загружаемся во вчерашнюю систему, после чего с НАСа подтягиваются измененные за сегодня файлы (в моем случаи все это через 10 гигабит — так что толком и кофе не успееешь попить
зы, ну а если нуже отдельный файл то он просто лежит на НАСе (если конечно его сохранили локально), на НАСе много тера так что никакая компрессия не используется — данных которые компрессируются все равно мало)
У меня простая связка:
Veeam Endpoint Free (он есть для винды и для всех линюхов, бесплатный даже для серверов и для бизнеса, живут они за счет платных версий с плюшками)
+
SyncThing
принцип такой: инкрементальный образ ночью на свой NAS (zfs) + Syncthing на те папки где данные меняются в течении дня
результат:
имеем вчерашний образ системы — полетел диск например
+ все файлы которые меняются на компе лежат на НАСе (там снэпшоты ежедневные, на всякий случай)
1. Логин/пароль хранятся в командном файле в открытом виде. Скомпрометировав управляющий компьютер злоумышленник может уничтожить и все хранилище.
2. При сохранении в облаке или внешнем хранилище есть еще опасность перехвата трафика и аутентификационных данных на шлюзе методом MITM. А если используем не HTTPS, а FTP, то и MITM не понадобится — достаточно перехватывать и анализировать протокол FTP.
3. А как там насчет производительности? Посчитаем на моих данных:
Допустим, хочу сливать 2 раза в сутки все наборы архивных данных в облако. Их по разным серверам набирается свыше 80 Гб. Это не считая архивов журналов транзакций.
Провайдер дает канал 16 Мбит/с на вход и выход.
Если слив будет идти на полной скорости и не будут тормозить ни сервера, откуда идет слив, ни само облако, то потребуется более 11 часов. Т.е. времени — впритык. Если какая-то небольшая задержка, то уже гарантированно не успеваем завершить цикл до начала следующего.
Другими словами, предлагаемая схема хоть и проста и понятна, но не обладает ни необходимой надежностью, ни необходимой производительностью.
2. Именно для этого архивы шифруются на Вашем компьютере. Сделайте пароль к архиву «соленым» — исходный пароль к хранилищу + соль + хэш — и собственно все. Аналогично кстати и логин выше можно использовать условный, хэш пароля = учетная запись на яндексе.
3. Если это «цельнолитые» данные — т.е. огромные файлы, которые меняются как они есть — то да, это будет работать по 11 часов, или нужно искать программу для поблочного копирования. Если же это данные, которые находятся в куче мелких файлов, которые меняются не сразу 80 гигабайт за раз — к примеру у меня dokuwiki, из 27 000 файлов меняется ежедневно только тысяча — то инкрементный архив обычно составляет десяток-другой мегабайт и заливается за секунды.
А еще смешивать личное и профессиональное — моветон. Для целей корпоративного хранилища лучше завести отдельный аккаунт. Ну и это не обязательно должен быть Яндекс-диск.
2. А при чем здесь парольное шифрование архива? Я имел в виду, что пароль может быть перехвачен на шлюзе (в т.ч. аппаратном) даже при передаче по HTTPS. После чего некоторое время сохраняемые архивы заменяются мусором. А потом уже в дело вступает червь-шифровальщик. Либо пусковым сигналом для него служит попытка чтения архивов из хранилища.
3. Да, именно «цельнолитные». Полная резервная копия одной SQL-базы весит от нескольких Гб до нескольких десятков. Набор (одним файлом), включающий полную резервную копию и несколько резервных за двое суток — еще на несколько Гб больше.
Их даже архивировать и паролить отдельно не надо — все это делается непосредственно средствами SQL.
Хотя, есть еще несколько старых файл-серверных БД, которые состоят из десятков и сотен отдельных файлов. Вот они как раз архивируются внешним архиватором, только не 7Z, а RAR. Раз в неделю полная копия и 1-2 раза в сутки инкрементные. Тут как раз такой случай — инкрементные занимают несколько сот Кб, но полные — все равно около 10 Гб.
Так что, когда по расписанию приходит время скидывать все наборы и полные архивы, то понимаешь, что канал провайдера не в состоянии этого обеспечить.
Сейчас будем внедрять похожую систему «дальнего» слива. Правда, не в облако, а на территорию склада в 300 м от основной конторы. Зато по оптическому каналу и без уязвимости паролей. Пришлось докупить кое-какое оборудование по мелочам. Когда отладим — отпишусь.
Эх… Когда mail.ru к своему облаку так разрешит…
Все то же самое умеет Cobian Backup. Который умеет и VSS. Плюс удобнее.
Выше в комментариях писали про использование клинтов облачных хранилищ.
Если Вы про то, что Cobian не умеет работать с облаками напрямую — да, не умеет, упустил этот момент.
В лучшем случае можно будет из облака попытаться достать предыдущие версии этих файлов. Но это в том случае, если хранилище поддерживает версифкацию файлов и места в нем для этого достаточно. В худшем…
В подшефной конторе просто поднял ftp на NAS. Cobian складывает копии на ftp, по SMB доступа к NAS нет. Решил, что так проще, чем городить костыли.
А еще вместо этого можно дополнительно шифровать все файлы объемом свыше 100 Mb. Архивы, резервные копии БД, образы дисков обычно весят больше.
Про FTP — идея правильная. Но не совсем. Потому что оригинальный FTP не шифрует аутентификационные данные. Либо использовать FTP over SSH, либо использовать расширения FTPS, которую NAS может и не поддерживать.
И то не уверен, что FTPS шифрует аутентификационные данные.
Таким образом, аутентификационные данные передаются в открытом виде. А, следовательно, могут быть перехвачены, проанализированы и скомпрометированы. После чего на NAS поступит команда стереть или переписать хранящиеся на нем файлы мусором.
Сервис на фтп сервере может перемещать файлы в недоступное для фтп пользователей расположение.
+
Отключение получения списка файлов в каталоге так же решает проблему с угрозой перезаписи файлов. Не получив список файлов, Вы на фтп сервере ничего не перезапишите и не удалите, можно только фигачить наугад надеясь попасть в имя файла, однако если система резервного копирования создает имена файлов на основе хэшей блоков, это будет весьма проблематично.
Перенос в недоступное место не является панацеей, но идея интересная. хоть и требует развития.
Прежде всего, остаются 2 проблемы:
1. Между помещением файла в FTP-хранилище и переносом в недоступное место, может пройти некоторое время, достаточное для проведения деструктивных действий.
Далее они будут скопированы в «недоступное» место уже измененные. При этом в «недоступном» месте, возможно, будут удалены предыдущие самые старые версии. После нескольких таких циклов годных копий не останется.
2. Файлы уже могут быть скопированы на FTP в
Есть идея, которая полностью не решит эти проблемы, но может снизить риски.
Заключается в использовании файлов-триггеров, содержащих контрольные суммы (КС) переданных файлов. Происходит следующее:
1. По расписанию на стороне FTP-сервера проверяется наличие файла-триггера. Если он есть, то:
2. Закрывается соединение по FTP.
3. Проверяется целостность файла-триггера.
4. Извлекаются из него КС полученных файлов.
5. Если КС совпадают, то освобождается место под них в «недоступном» хранилище и файлы переносятся туда. Триггер стирается.
6. Если все нормально, то FTP-открывается, иначе — алярм!
Но это позволяет контролировать целостность файлов только в промежутке между вычислнием КС и обнаружением триггера на стороне FTP-сервера. Если же архивы были зашифрованы/испорчены раньше, чем вычислены их КС, то это не поможет.
Как вычислять КС резервных файлов методами SQL на этапе создания — не знаю. В файле резервного копирования хранится КС для каждой резервной копии из него, но не всего файла. А еще есть файловые БД (хоть их у нас и немного осталось), которые просто архивируются сторонним архиватором.
Можно, конечно, среди резервных файлов разместить файл-ловушку (honeypot), с известной контрольной суммой. Но тогда надо его каждый раз переписывать свежим (даже если он не изменяется), а то зловред может проигнорить древние файлы. И, да, этот горшочек меда тоже не должен быть слишком маленьким, чтоб не показаться ему не стоящим внимания.
PS. Кстати, в этом случае «недоступное» место можно сделать в облаке. Но копировать в него не несколько раз в сутки, а 1-2 раза в неделю.
По маске Вы ничего удалить не сможете, поскольку маска не возвращает Вам список файлов. В конце концов можно банально запретить ftp-учетной записи удаление на уровне файловой системы.
Про битые файлы уже давно все придумали, кладете рядом текстовый файл с контрольной суммой, принимающая сторона проверяет, если что то не так: алярмит. Но это больше к проблемам транспорта относится, чем к атаке шифровальщика.
Быстрое и надежное резервное копирование данных в облако