mayton2019

Боюсь что процесс дедупликации будет требовать ресурсов гораздо больше чем сам backup.

Попробуй сам подумать какая асимптоматика будет у алгоритма поиска в одном файле фрагментов другого
файла.

Из коробочных инструментов есть fdupes. Я им пользовался когда надо искать в большом архиве pdf
документов такие-же документы дубли или фолдеры-дубли. Но fdupes просто ставит более простую
задачу. Ищет полное совпадение всех файлов со всеми. Вот. А если ты будешь играться с дифференциальными
или прочими бэкапами то сложность твоей задачи еще более вырастает.

Лет 10 назад можно было на барахолках купить стриммеры HP. А кассет было много на предприятиях. Некоторые впоследствии на радиорынках продавались еще в нераспечатанном виде. Производитель лент гарантировал что-то вроде 15 лет хранения информации (при условиях правильной температуры и влажности). Это - самые длительные сроки что я видел. Размер касеты у них кажется был 20-40Гб.

Еще Verbatim продвигал какие-то особо прочные DVD+R диски с алмазным покрытием. А по объему кажется это были 4.7G Надо посмотреть я не помню точно. Вобщем надо искать + еще покупать пищущее устройство.
А сейчас даже ноуты продают уже без DVD привода.

Я у себя дома храню на двух HDD дисках серии WD-Green. Конечно непонятно что делать если от времени сгорает
контроллер но вроде как 2 сразу в один день не должны сгореть.

Идея регулируемого тарифа заложена например в AWS S3 хранилище. Там вы для старых файлов можете просто задать атрибут storage class и указать более жлобские модели хранения вплоть до ленточного архива. Но установкой атрибута класса хранения вы будете сами управлять.

Очень сильно стоит вопрос определения "старости файлов". Я-бы учитывал частоту доступа за период. К пример кто-то может интересоваться старыми проектными файлами и алгоритм балансировки должен это как-то учитывать.

И внешнаяя ссылка на файл вообще не должна изменяться.

Если исходники хранит - то наверное git подходит.

Если фильмы и музыку - то наверное надо другой подход обсудить. Вобщем ты мало информации сказал.

Хочу при помощи tar сохранить все конфиги, но метаюсь между выбором директории home и ~/.config

Дык тебе не надо метаться. Тем более что никто не сможет ответить нужен ли тебе home целиком или нет.
Если места достаточно то бэкапть все что можно.

Но проблемы бэкапа только начинаются после того как он сделан. Ты разверни виртуалку и попробуй потом восстановить все конфиги (и приложения!!) с этого бэкапа. Я гарантирую сюрпризы.

Вобщем пробуй сам. Для бэкапа всех поддиректорий с точечками - можно написать скрипт. Но проблема
не в этом на самом деле.

Tar и gzip это очень старые утилиты. Им по 30-40 лет. И создавались они в те времена когда симметричное шифрование еще не было так развито.

Но архивчик можно после упаковки зашифровать другими утилитами например openssl.

openssl enc -in file.txt -out encypted_file.txt -e -aes256

Я так делал когда шифровал бекапы oracle dbms.

Если переписать чуть лучше скрипт - то можно объединить операции tar->gzip->openssl в один пайплайн
без воздания промежуточных файлов.

Насколько я понимаю - нужно вначале на основе сделать гит и из него разворачивать, а как быть с созданием копии бд?

Посмотрите на liquibase и flyway. Они спецом создавались чтобы обновления на базу катились через git.

Я думаю что в организации никто не одобрит твои улучшения. А если ты хочешь сказать что система бэкапа плохая - то объяви о том что проводишь учебную тревогу с имитацией полного процесса восстановления. Проведи. Запиши протокол. Что. Как. Какие баги.

Таких программ много. Это средства версионного контроля например git. Сделай git init в каталоге и делай каждый раз новый commit при резервном копировании. Для перемотки назад можно использовать стандартный git checkout с указанием хеша коммита или комменатрия или любого другого поискового признака которы ты знаешь как владелец бэкапа.

Беря во внимание что git все таки больше предназначен для текста чем для бинарей возможно в его использовании есть какие-то нюансы. Но я с ними не сталкивался пока. Можно еще почитать про git LFS https://git-lfs.github.com/

Версионирование бекапов также встроено в файловую систему XFS. Там есть утилиты для dump/restore. Но мне их подход не очень понравился. Хлопотно.

UPD: Да еще. Забыл. Версионирование ФС (настоящее) точно встроено в докер overlay-fs. Но как им воспользоваться в случае автора я пока не знаю. Может знающие - подскажут.

Был в десятке разных компаний. У всех - по разному.
Бэкап это по большей части организационный вопрос. Главное что в этом топике вам никто правильно не ответит.

Нужно спрашивать ваш бизнес о требованиях к базе. Например:

1) Как долго бизнес согласен ждать восстановления? Это влияет например на стратегию делания инкрементальных кумулятивных и полных бэкапов для БД. Разумеется все БД - в режиме arhivelog/wal.
2) От чего мы страхуемся? От физических повреждений. Или еще нужно предохранится от неверно поставленного обновления на базу. Тут - надо прикупить дополнительных дисков или магнитных накопителей.

Самое главное что у вас должны быть учебные тревоги. Тоесть вы должны реально откатать бэкап+восстановление хотя-бы несколько раз. Иначе то что вы делаете будет фейком. Часто видел такое. Бэкап делает какой-то сисадмин средствами Акрониса например. Но этот сисадмин и понятия не имеет как работает Oracle и что вообще нужно предварительно подготовить чтоб бэкапные файлы не стали ненужным балластом.

Правильно выше пишут. Технически tar+cron решает эту задачу. И обычно самое простое решение - самое надежное. Если "хочется отслеживать" - то это уже другая задача. И она не имеет прямого отношения к бэкапу. Тоесть вопрос состоит из двух независимых частей. Собственно бэкап. И какой-то мониторинг который должен ... что то мониторить.