LINUX.ORG.RU

Способы отслеживания изменений директории рекурсивно

 , ,


0

2

Чтобы не создавать полные бекапы тех же данных, когда нужно создавать именно полные бекапы, но только при наличии изменений с момента предыдущего бекапа, ищу наиболее простой и эффективный способ отслеживания изменений. По сути мне не нужно знать, какие файлы изменились, что в них изменилось, а достаточно знать о факте изменения даже 1 файла.

Действие происходит на десктопе, не на сервере. Десктоп включается и выключается.

Сейчас в голову приходит отслеживание статистики по файлами. Для бекапов, которые делаются 1 раз в день по расписанию

find /source -mtime -1 -print -quit

Если есть хотя бы 1 строка в выводе - запускать бекап. Разумно или стоит применить что-то другое?

Разумно или стоит применить что-то другое?

если ты хочешь бэкапить систему, то самый тупой и самый надёжный способ, это раз в неделю выключать систему, подключать второй диск и делать копию через dd if=/dev/sda of=/dev/sdb.

никакие другие софтварные ухищрения не дадут тебе 100% гарантии, всё остальное есть суть костыли, когда речь заходит про бэкап операционной системы, тем более «на горячую».

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

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

RAID 1, зеркальная копия двух дисков. все изменения на одном диске, приводят к измнениям на другом. и в случае удаления файлов на одном диске, файлы на втором тоже будут удалёны.

если тебе такой способ бэкапа (зеркалирования) подойдёт, создавай RAID 1 массив из двух дисков хотя бы.

и лучше в таком случае будет собрать отдельную железку (домашнее облако) для хранения данных.

накатить туда хоть FreeNAS уже готовый, пусть рулит дисками и занимается бэкапами. и предоставляет тебе доступ к файлам через какой-нибудь веб-интерфейс типа nextcloud, или samba, или dlna, или ещё чего. любое решение по желанию.

Spoofing ★★★★★
()
Ответ на: комментарий от Spoofing

Что-то тебя понесло. Я не писал, что мне нужно бекап диска. Я делаю бекап нужных данных, которые потом могу открывать с linux/macos/windows. Поэтому то, что ты написал, это не мой случай.

NightWillCome
() автор топика
Ответ на: комментарий от Spoofing

А, я понял, ты рекламируешь свою поделку. Спасибо, не нужно.

NightWillCome
() автор топика

«Дурная голова ногам покоя не дает.»

в голову приходит отслеживание статистики по файлами

Живая система в режиме персистент.

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

andytux ★★★★★
()
Ответ на: комментарий от andytux

Дурная головая не позволяет прочитать, о чем речь идет в теме, а заставляет сразу бежать советовать ненужные вещи.

NightWillCome
() автор топика
Ответ на: комментарий от Kroz

Всем устраивает. Его и использую в качестве инструмента для переноса данных на диск с бекапами.

NightWillCome
() автор топика
Ответ на: комментарий от andytux

Что ты балерина в аквадискотеке? Нет, не ошибся. Продолжай танцевать.

NightWillCome
() автор топика

Кроме полных бекапов есть и инкрементальные, зачем нужно знать какие изменения происходили, возьми borg или restic они сами по дате модификации файла поймут и сделают инкремент так еще с дедупликацией и компрессией файлов.
Если хочешь дергать каждый раз как изменился файл тогда читай про inotify.

Samamy ★★★
()

Разумно

Да.

стоит применить что-то другое?

Нет. Ты всё сделал правильно самым простым и надёжным способом.

LamerOk ★★★★★
()

Разумно или стоит применить что-то другое?

Неразумно. Тебе никто не даст 100% гарантию целостности предыдущего бэкапа, и если ты будешь бэкапить только изменения, в случае 3.14-здеца тебе придётся откатываться на состояние отличное от текущего, возможно даже сильно отличного.

Если ты бэкапишь всю систему, то её следует останавливать, иначе данные в архиве будут неконсистентны. Если проект, то стоит делать коммит в VCS, а для бэкапа переходить на коммит, а не бэкапить HEAD. С пользовательскими данными проще, но тоже можно напороться на неконсистентность.

Так что @Spoofing прав по поводу остановки, но вот его предложение с dd я не поддерживаю. ☺

mord0d ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.