- быстрое (идеально в фоне);
- сохраняло бы как актуальную версию файлов, так и предыдущие;
- хранилище файлов было бы недоступно вирусам или стихийным бедствиям типа уничтожения носителя или его воровства;
- содержимое резевной копии было бы доступно только пользователю, т.е. паролировалось.
Существует множество предложений для этого, но ни одно из них не выполняет задачи полностью. Легкое простое копирование не дает быстроты, быстрое сохранение не дает надежности, копирование на внешний жесткий диск не дает гарантии его кражи.
Однако, уже давно существуют инструменты для решения задачи. Главное правильно применить Unix way и командные файлы. И самый простой вариант — заархивировать файлы в один архив и отправить его в онлайн-хранилище, используя командную строку. Для ускорения работы задача делится на 2 этапа — сначала создается и отправляется в онлайн-хранилище полный архив, потом по мере необходимости создаются инкрементные архивы, что дает скорость. Шифрование архивов обеспечивает безопасность данных.
Что требуется для решения задачи:
- аккаунт в яндексе, чтобы получить доступ по webdav к яндекс-диску. Применение любого другого хранилища не возбраняется;
- 7z — консольный архиватор, распространяется бесплатно;
- curl — консольный инструмент для работы с интернетом, распространяется бесплатно.
Для портабельности я положил 7z.exe, 7z.dll и Curl.exe в один каталог. В зависимости от того, как был скомпилирован Curl.exe, может быть необходимо будет положить рядом или добавить в систему библиотеки libeay32.dll, libssh2.dll, msvcr100.dll, MSVCR110.dll.
Далее в этом каталоге желательно сформировать каталог, в который нужно поместить файлы и каталоги для будущего архива. У меня он называется «backup» и в него я помещаю жесткие ссылки на файлы или связь каталогов (соответствующий функционал есть в FAR по комбинации клавиш Alt+F6). Таким образом, я могу, не меняя структуру существующих данных, создать удобную мне структуру для резервого копирования.
Следующий каталог — «temp». Предназначен для хранения архива данных перед отправкой его на сервер. Заодно он будет являться зашифрованной копией актуальных данных, что обеспечивает дополнительное их резервирование на случай атаки вирусов.
После чего в исходном каталоге нужно создать достаточно простой bat (cmd) файл «full.bat» следующего содержания:
@echo off
set filebkp=work
set pathbkp=backup
set srvbkp=https://user:password@webdav.yandex.ru/backup/%filebkp%
set pathtemp=temp
set full=%filebkp%-full
del /F /Q "%pathtemp%"7z.exe a "%pathtemp%\%full%".7z -x!*.log; -r -mx1 "%pathbkp%\*" -ppass_for_archive
curl.exe -k -X DELETE "%srvbkp%" --verbose -o .\stdout
curl.exe -k -X MKCOL "%srvbkp%" --verbose -o .\stdout
curl.exe -k -T "%pathtemp%\%full%".7z "%srvbkp%"/ --progress-bar --verbose -o .\stdout
- set filebkp=work — задание общего названия компьютера и пути на сервере, по которому будет храниться резервная копия. Т.к. компьютеров может быть несколько, то это может быть резервная копия рабочего компьютера (work), домашнего (home), ноутбука (book), указание индивидуального названия не позволит копиям смешиваться друг с другом.
- set pathbkp=backup — задание пути к каталогу, где хранятся данные для резервного копирования, в данном случае указан каталог с жесткими ссылками и связями каталогов, который Вы должны были создать ранее.
- set srvbkp=https://user:password@webdav.yandex.ru/backup/%filebkp% — задание каталога на сервере, куда будет заливаться резервная копия. user и password — пароли от Вашей учетки на яндексе;
- set full=%filebkp%-full — задание заранее названия архива.
- del /F /Q "%pathtemp%"\ — удаление (очистка) временного каталога
- 7z.exe a "%pathtemp%\%full%".7z -x!*.log; -r -mx1 "%pathbkp%\*" -ppass_for_archive — строка запуска архиватора. pass_for_archive — Ваш пароль к архиву.
- curl.exe -k -X DELETE "%srvbkp%" --verbose -o .\stdout — удаление на сервере каталога назначения.
- curl.exe -k -X MKCOL "%srvbkp%" --verbose -o .\stdout — заново создание на сервере каталога назначения.
- curl.exe -k -T "%pathtemp%\%full%".7z "%srvbkp%"/ --progress-bar --verbose -o .\stdout — заливка с помощью curl архива на сервер.
Таким образом, запустив скрипт «full.bat», Вы получите полную версию Ваших файлов в архиве в каталоге «temp» и ее же в каталоге «backup/work» на сервере, зашифрованную Вашим паролем. Это может занять определенное время и имеет свои ограничения по объему архива, но самые важные и при этом ежедневно меняющиеся данные стоит заархивировать именно таким образом.
Почему важные и ежедневно меняющиеся? Потому что следующий скрипт, «inc.bat», позволяет найти и отправить на сервер в инкрементный архив измененные данные, отличающиеся от полной версии:
@echo off
set filebkp=work
set pathbkp=..\backup
set srvbkp=https://user:password@webdav.yandex.ru/backup/%filebkp%
set pathtemp=..\temp
set full=%filebkp%-full
set inc=%filebkp%-inc
set h=%TIME:~0,2%
set m=%TIME:~3,2%
set s=%TIME:~6,2%
set ms=%TIME:~9,2%
set curtime=%h%-%m%-%s%
set dd=%DATE:~0,2%
set mm=%DATE:~3,2%
set yyyy=%DATE:~6,4%
set curdate=%yyyy%-%mm%-%dd%
set curdatetime=%curdate% %curtime%
7z.exe u "%pathtemp%\%full%".7z -x!*.log; -u- -up3q3r2x2y2z0w2!"%pathtemp%\%inc%".7z "%pathbkp%\*" -ppass_for_archive
ren "%pathtemp%\%inc%".7z "%inc% %curdatetime%".7z
curl.exe -k -T "%pathtemp%\%inc% %curdatetime%".7z "%srvbkp%"/ --progress-bar --verbose -o .\stdout
Расшифровать этот файл я думаю Вы сможете сами — скрипт с помощью 7z анализирует уже имеющийся в каталоге «temp» полный архив и исходный каталог, находит изменившиеся файлы, запаковывает их в инкрементный архив, именованный по текущей дате и времени, и отправляет на сервер. Таким образом, если полная архивация занимает скажем 1 гигабайт и 3 минуты времени, то измененные файлы обычно занимают 10-50 мегабайт и улетают на сервер за несколько секунд. Поместив «inc.bat» в планировщик заданий Windows, Вы позволите этому процессу происходить по расписанию в удобное для Вас время, что позволит забывать о нем.
Когда же Вам покажется, что время создания инкрементных копий стало слишком большим, можно снова запустить «full.bat» — это очистит все каталоги от полных и инкрементных архивов и создаст свежий вариант полной версии.
Комментарии (47)
immaculate
07.06.2018 04:20Уже есть утилита, которая делает инкрементальный бэкап на любые носители (в т.ч., облака, а также может передавать через ftp, scp, rsync): duplicity. Правда, не знаю, работает ли она под Windows, но уверен, что работает.
При этом в ней миллион настроек, что включать в архив, что исключать, какого размера делать тома, шифровать ли GPG, как часто пересоздавать полный архив, и так далее.
Я ей делаю копии в два разных места: на флешку 64 Гб, и внешний жесткий диск. Еще как минимум два production сервера у меня бэкапятся duplicity на Amazon S3. Уже несколько раз приходилось восстанавливать файлы недельной давности из инкрементального бэкапа. Все делается очень просто, в отличие от скрипта в статье, не придется вручную искать нужный архив и вручную извлекать содержимое.
aik
07.06.2018 06:59Для windows есть Duplicati.
DaMaNic Автор
07.06.2018 08:58Duplicati как аналог duplicity на windows есть, и его можно использовать.
Вопрос — я на работе хочу посмотреть последнюю версию файла из дома (например какой нибудь чертеж или расчет, который я редактировал х дней назад). Я знаю что я могу в моей версии скачать последний или любой после дня х инкрементный архив и взять его оттуда — он там точно будет, для открытия не нужно ничего кроме как залезть в хранилище и скачать файл архива. Почему именно это действие? Потому что я веду бухгалтерию и делаю подработки, и поэтому у меня всегда возникает нужда посмотреть последние версии Excel, Word и Autocad документов.
Что нужно сделать чтобы из архива Duplicati на моем рабочем месте извлечь аналогичные файлы? Ставить / разворачивать архив с Duplicati на работе просьба не предлагать — проблемы с админскими правами я еще могу обойти (портабельная версия), но следы работы этого программного обеспечения не скрыть, со всеми вытекающими.immaculate
07.06.2018 09:16Написано, что duplicati — это практически 1-в-1 порт duplicity. Значит, во-первых, можно напрямую работать с файлами — у duplicity структура довольно самоочевидная, можно разобраться и вручную, в каком архиве что лежит. Во-вторых, раз есть portable версия, можно с ее помощью вытащить файл из резервной копии.
Если запрещено в принципе запускать сторонний софт на рабочем компьютере, то остается лишь первый вариант, конечно. Но это уже не техническая проблема.
DaMaNic Автор
07.06.2018 10:35Проверил все предположения.
Консольная версия 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=«пароль_для_шифрования»DaMaNic Автор
07.06.2018 11:11И тут же первая проблема:
При попытке получить обновление уже скачанной версии архива 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:\…
aik
07.06.2018 10:30Задача резервного копирования и задача доступа к файлам обычно разными способами решаются.
DaMaNic Автор
07.06.2018 11:25Например, какие разные способы резервного копирования и последующего доступа к ним Вы применяете, сев на компьютер, на котором у Вас не установлены никакие оснастки и программы для резервного копирования и прав администратора у Вас там тоже нет?
Обычный рабочий или бытовой компьютер с ограниченной учетной записью, windows xp-7-10 Home Editionaik
07.06.2018 12:01Если на компьютере ничего не установлено, то это обычно не мой компьютер и задача резервного копирования не стоит — есть админ, пусть он и отвечает.
А к своим компьютерам доступ через браузер есть, к примеру.
DaMaNic Автор
07.06.2018 08:54duplicity только под linux, под windows предлагаются невразумительные или даже платные порты. И да, именно поэтому я отметил пользователей windows, потому что под linux есть самые разнообразные способы выполнения этой задачи, включая создание зашифрованной копии файлов в онлайн хранилище в виде части файловой системы.
SidMeier
07.06.2018 10:45Acronis TI?
Alert123
07.06.2018 11:53А наподобие Acronis ничего не посоветуете? Раньше им пользовался, но последние версии перестали работать, ломают загрузку системы. Перешел на CrashPlan, но не очень нравится. Хотелось бы чтобы бэкапы были всего диска а не пофайлово. Есть другие готовые программы для Windows?
DaMaNic Автор
07.06.2018 12:021) Бесплатный и портабельный? — нет, платный и требует установки.
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, что будет учтено в Ваших платежах за использование.
Вывод — честное бытовое использование вызывает сомнения в силу платности и ограниченности, ну а за деньги и при корпоративном применении — почему нет?Alert123
07.06.2018 12:21Платные сервисы бэкапов стоят совсем недорого даже для частных лиц, время куда дороже.
К тому же всякие 7z/rar просто несправляются когда очень-очень много мелких файлов. Пробовал как то, сделать архив моего диска с проектами WinRar показывает около 2 суток даже при минимальной компрессии. А вот платные программы бэкапов справляются с этим куда быстрее, всего часа за три.DaMaNic Автор
07.06.2018 12:38Если архив диска делается не пофайлово, а целиком диск, поблочно, то это делается всегда быстро — ограничение лишь в скорости работы самого диска и интернет-соединения. Естественно, сжатие отсутствует как факт, шифрование тоже под вопросом. Касательно работы архиваторов — 27 тысяч файлов 7z в быстром режиме зажимает в течении 40 секунд, интрементный архив при изменении тысячи файлов создается и заливается за 5 секунд. Если экстраполировать эти данные на Ваш архив, получается что Ваш рабочий каталог содержит минимум сотню-другую миллионов файлов, с которыми Вы постоянно работаете, и тогда да, это проблема, или же это просто огромные файлы баз данных, которые невозможно архивировать инкрементно, и тогда да, создать образ диска — лучший выбор.
Alert123
07.06.2018 13:23нет, даже пофайлового у других решений быстро работает, и шифрование со сжатием там есть. Как пример CrashPlan именно пофайлово работает.
SidMeier
08.06.2018 16:06Специально посмотрел в начало Вашей статьи — не встретил не одного из этих пунктов.
Взамен могу предложить свои пунктики по поводу Вашего решения:
1) Имеет поддержку? — нет, автор один, его компетентность не подтверждена…
2) Не требует повышенного внимания? — требует, и ещё как требует
3) Легко и быстро позволяет создавать резервные копии? наверное, не проверял, наверное потому что требования пунктов 1 и 2 отбивают охоту к проверке.
4) Кроссплатформенно из коробки? — ага, «легко можно переписать примерно на 100 других вариантов командных оболочек»
Вывод — честное бытовое использование вызывает сомнения в силу сырости и ограниченности.DaMaNic Автор
08.06.2018 16:56Все все, уели )) не буду продавать это по 3700 за лицензию на год или 5300 за бессрочную лицензию ))) сдаюсь )). Особенно понравилось то, что bat файл требует «поддержки и внимания», добавили бы еще «технического обслуживания по регламенту и привлечения специалистов минимум уровня архитектора приложений» и я был бы раздавлен раз и навсегда ))) остальные пункты из той же серии ))) в самом деле, скриптовый файл жестко привязан к платформе из-за огромного количества зависимостей, и не может быть перенесен в другую систему, кроме как полностью переписан с привлечением независимой команды разработчиков. Позор мне )))
Sergey-S-Kovalev
07.06.2018 13:22| set srvbkp=https://user:password@webdav.yandex.ru/backup/%filebkp%
Вы предлагаете сохранить в открытом виде логин/пароль от учетной записи в которой у меня деньги лежат? И это не говоря уже про тот же пароль от архива в открытом виде в том же файле.
Эээ. Нет, спасибо.DaMaNic Автор
07.06.2018 16:24Я специально делаю акцент на портабельности решения, чтобы упрятать его в скрытое место/самораспаковыющийся архив, который выполнит работу и удалит все распакованное после выполнения. Как вариант отредактировать скрипт для ввода пароля по требованию, причем сделать пароль на архив «соленым» ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BB%D1%8C_%28%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%8F%29 — тогда будет меньше паролей для ввода у Вас и больше проблем у тех, кто попытается стащить и расшифровать архив с онлайн-хранилища.
И еще раз — это решение не для промышленных систем резервирования и защиты информации, это скорее бытовое применение, когда вероятность стащить у Вас пароль от хранилища примерно равна вероятности что у Вас стащат все остальные пароли и файлы вместе взятые. Если у Вас периодически взламывают компьютер и с него уходят в сеть все Ваши файлы и данные, а сам он становится хабом для дос-атак — Вам это решение точно не подойдет.Sergey-S-Kovalev
08.06.2018 06:01Я понимаю, что Вам на текущей стадии это решение кажется оригинальным и очень удобным, тем более оно самописанное, в него душа вложена. Но нужно понимать, что пользователем этого решения будете только Вы. Решение по бэкапу взаправдашнее только тогда, когда Вы про него забываете, а через 5 лет он вам понадобился и Вы смогли из него восстановится. У Вас же собраны все возможные факапы связанные с реализацией процесса резервного копирования:
— Использование CMD.
— Используя скриптинг, Вы не используете ключи
— Не бэкапятся открытые файлы.
— Все сделанные бэкапы находятся в состоянии суперпозиции, они вроде и есть, но если не произведено тестовое восстановление, их как бы может и не быть.
— Отсутствует уведомление в почту/мессенджер о удачном/неудачном действе, ошибках в процессе.
— Отсутствие проверки доступности источника, временной папки и хранилища.
— «безопасность» через «упрятать»,«посолить», «вероятность»
— Отсутствие прогнозирования и проверки достаточности места на диске с временной папкой и в хранилище
— Бесконечные инкременты, пока руками на полный бэкап не тыкнешь.
— При создании нового полного бэкапа, Ваш скрипт сначала сносит все старые бэкапы, а только потом делает полный новый!
Список могу продолжать еще долго, но и этого уже с лихвой хватает, что бы не использовать данное решение. Смените язык программирования, почитайте про правило 3-2-1, почитайте про идеологию резервного копирования впринципе. Прокурите реализацию доставки файлов в облако через родной клиент облачного хранилища. Напишите свой бэкап клиент. Офигейте от трудозатрат. Бросьте это дело.DaMaNic Автор
08.06.2018 08:13Прекрасно ) посмотрим что можно сделать по Вашему списку.
— Использование CMD — легко можно переписать примерно на 100 других вариантов командных оболочек;
— Используя скриптинг, Вы не используете ключи — вынести пути и так далее в ключи легко;
— Не бэкапятся открытые файлы — бекапятся. Не бекапятся только файлы, заблокированные на чтение. Через теневые копии (есть описание выше) можно и открытые и заблокированные файлы считать.
— Все сделанные бэкапы находятся в состоянии суперпозиции, они вроде и есть, но если не произведено тестовое восстановление, их как бы может и не быть — добавить в скрипт еще пару строчек на обратное скачивание и тестирование архива;
— Отсутствует уведомление в почту/мессенджер о удачном/неудачном действе, ошибках в процессе — добавить еще строчку с консольным mail — клиентом, реализующим данный функционал.
— Отсутствие проверки доступности источника, временной папки и хранилища — еще пару строк и еще немного данных для консольного mail клиента
— «безопасность» через «упрятать»,«посолить», «вероятность» — без комментариев, это вечное и реально проблемное место почти всех систем. unixforum.org/viewtopic.php?t=135935 для просто ознакомления, ну и решение — храните пароль в голове, вводите его в окошке.
— Отсутствие прогнозирования и проверки достаточности места на диске с временной папкой и в хранилище — увы, тут согласен
— Бесконечные инкременты, пока руками на полный бэкап не тыкнешь — отмечу, рабочие инкременты, которые мне и нужны. Я всегда знаю что в последнем инкременте лежит рабочий файл, если я с ним работал после создания полной версии бэкапа. В данном случае к примеру Duplicati ведет себя не лучше — бесполезно пытаться получить просто свежий файл, он всегда с сервера тянет полный бэкап;
— При создании нового полного бэкапа, Ваш скрипт сначала сносит все старые бэкапы, а только потом делает полный новый! — поменять строки местами, и сначала заказчивать тестировать, а потом сносить старый бэкап.
Таким образом, чтобы удовлетворить доброй половине Ваших желаний, всего лишь надо переписать скрипт с добавлением пары программ (использование теневых копий и консольного е-майл клиента), изменить порядок действий по проверке/удалению, и… бросить попытки курить трудозатраты на сложные системы, ибо овчинка выделки не стоит, ежедневную копию я уже имею, а отдельную копию на независимом носителе я и так делаю раз в две недели, что достаточно для домашнего использования.
И отмечу — скрипт можно использовать как пример логики, реализованной всего 2 программами. Расширить его можно всегда и любым способом. А курить родные клиенты облачного хранилища, или Duplicati с аналогами — поверьте, что курилось то курилось, список недостатков родных клиентов и программ «мы-вам-все-забекапим-по-феншую» будет еще длиннее чем указано у Вас по моему простенькому скрипту )))Sergey-S-Kovalev
08.06.2018 17:31Ладно, я понял что намек мой не понят.
Там не мои желания, там минимальный базис для любого скрипта резервного копирования, который можно раз настроить и забыть на пять лет. Дописать можно, я не спорю, но сейчас же этого нет. И строчки поменять, что бы логика правильно работала тоже можно, но изначально это опять же не реализовано. Уже сделано с ошибками из-за которых могут пострадать данные людей. А вся Ваша аргументация сводится к тому, что ну вот дописать всегда можно. Предлагаете сделать это сообществу? А смысл в статье тогда?
Ну я, возможно, понял бы если бы скрипт был жестью и адовым полотенцем, как делают немногие CMD-кодеры выкладывающие статьи сюда, но по факту ценность кода в статье нулевая. Просто потому что можно средствами архиватора делать фул и инкременты (напомню что атрибут «Архивный» именно для этого и существует), именовать файлы архивов по дате, а доставку в облако отдать клиенту облачного диска во имя секурности (некоторые из них уже сами умеют файло с локального диска перемещать в облако). Итого это одна строчка кода сразу забитая в таскшедулер. Я делал такую хрень (без облака) в 2002 году консольным винраром бэкапя базы 7.7 и дублируя нтбэкапом. Эта хрень даже до сих пор работает, не смотря на то что исходный 2003 сервак уже давно прошел через P2V процесс.
Не можете сами? Берете чужой скрипт, курите его логику, перелопачиваете код на свое усмотрение, добавляете своих перделок и собираете плюсы в сообществе. Некрасиво, но сойдет.
PwrUsr
07.06.2018 13:43Возьмем ситуацию — сегодня вечером полетел диск — мои действия (проверенно):
1. ставим новый диск
2. грузим Veeam recovery (с НАСа через PXE)
3. заливаем вчерашний образ на новый диск, перегружаемся.
4. загружаемся во вчерашнюю систему, после чего с НАСа подтягиваются измененные за сегодня файлы (в моем случаи все это через 10 гигабит — так что толком и кофе не успееешь попить
зы, ну а если нуже отдельный файл то он просто лежит на НАСе (если конечно его сохранили локально), на НАСе много тера так что никакая компрессия не используется — данных которые компрессируются все равно мало)
У меня простая связка:
Veeam Endpoint Free (он есть для винды и для всех линюхов, бесплатный даже для серверов и для бизнеса, живут они за счет платных версий с плюшками)
+
SyncThing
принцип такой: инкрементальный образ ночью на свой NAS (zfs) + Syncthing на те папки где данные меняются в течении дня
результат:
имеем вчерашний образ системы — полетел диск например
+ все файлы которые меняются на компе лежат на НАСе (там снэпшоты ежедневные, на всякий случай)
AlexanderS
07.06.2018 17:46Это все работает, когда надо бекапить несколько гигабайт данных. Но если размер защищаемых данных переваливает за пару сотен гигабайт, то все это становится долгим и тяжелым, становится неудобно.
DaMaNic Автор
07.06.2018 18:21Не спорю. Горстка файлов размером менее 2 мегабайт не может заменить промышленные системы в части обслуживания промышленных систем типа баз данных. Но они неплохо отрабатывают свое, когда собственно актуальные данные, с которыми ты работаешь ежедневно, меняются не так уж и массово — база данных домашней бухгалтерии, наработки по проекту в формате dwg, doc, xls, скромная домашняя dokuwiki на гиг и файлы настроек часто используемых программ, при этом все прозрачно, быстро и просто к пониманию. Та же duplicati например при экспериментах успешно забила 1 гигабайтом исходных данных 2 гигабайта на сервере, а при попытке сделать restore скачала все с сервера и сказала «новых файлов нет, спасибо что разрешили потратить ваши 5 минут времени впустую».
AlexanderS
07.06.2018 19:28Так вот и вопрос: какие надежные доморощенные варианты для тех, кто уже подбирается к полутерабайту? Я у себя локальный Nextcloud развернул, однако, как следует из четвёртой части моего повествования, без партизанщины типа BAT/AutoIt всё равно не обошлось — вот где будет пустая трата времени)
Pochemuk
08.06.2018 10:27Этот велосипед, кончно, любопытен, но есть несколько маленьких вопросов:
1. Логин/пароль хранятся в командном файле в открытом виде. Скомпрометировав управляющий компьютер злоумышленник может уничтожить и все хранилище.
2. При сохранении в облаке или внешнем хранилище есть еще опасность перехвата трафика и аутентификационных данных на шлюзе методом MITM. А если используем не HTTPS, а FTP, то и MITM не понадобится — достаточно перехватывать и анализировать протокол FTP.
3. А как там насчет производительности? Посчитаем на моих данных:
Допустим, хочу сливать 2 раза в сутки все наборы архивных данных в облако. Их по разным серверам набирается свыше 80 Гб. Это не считая архивов журналов транзакций.
Провайдер дает канал 16 Мбит/с на вход и выход.
Если слив будет идти на полной скорости и не будут тормозить ни сервера, откуда идет слив, ни само облако, то потребуется более 11 часов. Т.е. времени — впритык. Если какая-то небольшая задержка, то уже гарантированно не успеваем завершить цикл до начала следующего.
Другими словами, предлагаемая схема хоть и проста и понятна, но не обладает ни необходимой надежностью, ни необходимой производительностью.DaMaNic Автор
08.06.2018 14:541. Логин — обычно совпадает с Вашей же почтой на яндекс диск. Если о нем кто то знает — он и так скомпроментирован по умолчанию. Пароль — поменяйте на set /p pass=, получите интерактивный ввод пароля. Если и логин секретный — схема та же.
2. Именно для этого архивы шифруются на Вашем компьютере. Сделайте пароль к архиву «соленым» — исходный пароль к хранилищу + соль + хэш — и собственно все. Аналогично кстати и логин выше можно использовать условный, хэш пароля = учетная запись на яндексе.
3. Если это «цельнолитые» данные — т.е. огромные файлы, которые меняются как они есть — то да, это будет работать по 11 часов, или нужно искать программу для поблочного копирования. Если же это данные, которые находятся в куче мелких файлов, которые меняются не сразу 80 гигабайт за раз — к примеру у меня dokuwiki, из 27 000 файлов меняется ежедневно только тысяча — то инкрементный архив обычно составляет десяток-другой мегабайт и заливается за секунды.
slavius
08.06.2018 14:26Спасибо огромное! Как минимум — за способ работы с y.disk через командную строку. Ваш способ — это именно то, что мне и хотелось.
Эх… Когда mail.ru к своему облаку так разрешит…DaMaNic Автор
08.06.2018 14:56Пожалуйста. Выше кстати есть множество рекомендаций по модификации идеи, чтобы и верифицировать файлы, и пароль не оставлять в открытом файле, и прочее. Если когда нибудь выложите свой вариант реализации этой идеи — будет интересно посмотреть и применить.
Miller777
08.06.2018 15:47Интересно, но…
Все то же самое умеет Cobian Backup. Который умеет и VSS. Плюс удобнее.DaMaNic Автор
08.06.2018 17:09Отлично. У меня нет ftp, как прикрутить к Cobian Backup любое онлайн хранилище?
Sergey-S-Kovalev
08.06.2018 17:35Очевидно же. Отдать процесс загрузки файла на откуп клиенту облачного диска.
Miller777
08.06.2018 17:45Например, поставить приложение того же «Яндекс-Диска», делать бэкап в его папку, в облако он («Яндекс-Диск») сам положит.
Выше в комментариях писали про использование клинтов облачных хранилищ.
Если Вы про то, что Cobian не умеет работать с облаками напрямую — да, не умеет, упустил этот момент.
phaggi
А что будет, если файлы, которые надо скопировать в инкрементный архив, будут в момент запуска скрипта открыты на редактирование?
DaMaNic Автор
Если файл заблокирован (lock), то он будет пропущен. Если же просто открыт — сохраненная на диск версия будет залита на сервер, т.к. никто еще не придумал как выдергивать из памяти несохраненные данные.
antonn
«Теневые копии» умеют копировать файл в который ведется запись, в том числе при самом копировании (и учитывают проведенные изменения при этом).
DaMaNic Автор
Умеют. Есть вразумительные методы использования этого в консоли? Связка «обнаружить заблокированные файлы — выдернуть их в отдельный каталог», чтобы хотя бы потом отдельно заархивировать и отправить на сервер.
Andrusha
Зачем их отдельно обнаруживать? Делаем теневую копию всех бэкапируемых файлов, которая и отправляется в бэкап. Описание утилиты VShadow, примеры.
DaMaNic Автор
Тогда лучше взять пример из habr.com/post/115758, и модифицировать скрипты, приведенные в статье, с учетом использования снапшотов. Единственный тогда минус — доступ к администраторским правам, чтобы добавить пользователя, от имени которого запускается скрипт, в группу Backup operators.