Есть ли какие-либо проверенные временем стратегии, алгоритмы и форматы хранения данных с открытым исходным кодом, которые были бы полезны для разработки надежного и быстрого программного обеспечения для инкрементного резервного копирования для медленных сетевых дисков?
Я намерен использовать Qt framework или .NET (еще не решил), но язык программирования не имеет большого значения, потому что я ищу идеи и решения, а не код (хотя было бы неплохо иметь SDK или библиотеки).
Я не собираюсь создавать клиент-серверное решение уровня предприятия, но что-то простое, но все же настраиваемое под мои нужды.
Долгая история:
Я пытался найти надежное программное обеспечение для резервного копирования, которое поддерживает хотя бы простое запутывание как данных, так и имен файлов (шифрование XOR мне подойдет), а также может перечислять и извлекать отдельные файлы из резервного архива.
Я хотел бы выполнить резервное копирование на эмулированные сетевые диски (используя Expandrive или NetDrive).
Я пробовал много разных программ, но у каждой из них есть как минимум один критический недостаток. Некоторые программы слишком медленны для резервного копирования на сетевые диски из-за сложных алгоритмов. Некоторые программы сжимают все в большой zip-файл или файл пользовательского формата, который можно разделить на части, но если я пытаюсь перечислить и извлечь отдельные файлы, это обычно заканчивается тайм-аутом. Некоторые программы шифруют содержимое файлов, но оставляют имена файлов полностью открытыми, даже не запутывая их.
Я также пробовал некоторые специальные программы, которые делают резервные копии непосредственно в облачных сервисах, но они были слишком упрощены или не обеспечивали никакого шифрования для Google Диска, который я намереваюсь использовать в основном.
Вот почему я решил создать что-то индивидуальное, что я могу настроить по своему вкусу. Это было бы также возможностью для меня узнать, как правильно реализовать процесс резервного копирования.
В настоящее время моя идея состоит в том, чтобы разделить мою резервную копию на какие-то небольшие (100 МБ? 50 МБ? еще не уверен...) последовательно пронумерованные ведра (папки). Я могу сохранить файл блокировки в ведре, которое в данный момент выполняется. Если процесс резервного копирования прерывается и перезапускается, я могу проверить, существует ли файл блокировки, и тогда я знаю, что мне нужно перезапустить это ведро с нуля.
С этой системой корзин я должен был убедиться, что в каждой корзине есть полные файлы. Это означает, что если я храню файл размером 1 ГБ, я не могу разделить его на несколько частей, потому что это сильно усложнило бы работу с настраиваемыми таблицами адресации файлов и т. д. Таким образом, размер моей корзины — это просто рекомендуемая цель, но не что-то строгое.
Еще одна проблема заключается в том, как хранить список файлов и время их изменения, чтобы я мог реализовать инкрементное резервное копирование на основе меток времени и загружать список как можно быстрее. Я не уверен, что это хорошая идея хранить список файлов каждого ведра внутри этого ведра. Может быть, было бы лучше сохранить его в одном файле, чтобы я мог сразу его скачать? Но тогда я могу повредить этот список файлов и не смогу его восстановить. Поэтому кажется, что лучше хранить списки файлов в корзинах, но я не уверен, что ничего не упускаю.
Для шифрования, как я уже сказал, мне подойдет простой XOR, но если мне нужно что-то получше (и более ресурсоемкое), я мог бы добавить немного AES — для этой задачи существует множество библиотек. Я хотел бы также зашифровать списки файлов. Но я не уверен, что мне делать с файлами - шифровать каждый из них по отдельности или шифровать всю корзину?
Что меня больше всего беспокоит, так это надежность. Как проверить, не повреждены ли файлы в архиве? Коррупция — одна из причин, по которой я храню архив в ведрах. Если данные будут повреждены, только один или несколько сегментов будут повреждены. Но как обнаружить коррупцию? Я мог бы посчитать контрольные суммы, но я не уверен, как это сделать быстро и для чего мне их вычислять - для отдельных файлов? Целые ведра? И какой алгоритм использовать, чтобы процесс резервного копирования не замедлялся из-за подсчета контрольных сумм?
Я мог бы реализовать дедупликацию следующим образом. При резервном копировании у меня оба списка файлов (серверный и локальный) находятся в памяти. Если я встречаю два вхождения имени файла, я могу сделать контрольную сумму, чтобы увидеть, совпадают ли они, и если они совпадают, я сохраняю файл только в одном ведре, но в списке файлов второго ведра я отмечаю, что файл дублируется другого файла, который хранится в первом ведре, и при восстановлении из архива я могу извлечь этот единственный файл и скопировать его в оба места.
Все эти вопросы приводят меня к еретической идее — может быть, я мог бы использовать git?
Но я сомневаюсь, что это хороший инструмент для резервного копирования 100 ГБ данных. По крайней мере, я мог бы узнать некоторые полезные приемы от git, но опять же я не уверен, какие идеи будут работать или не будут работать для целей резервного копирования.
Если кто-то работал над подобной реализацией, было бы здорово услышать о вашем опыте и, возможно, о некоторых идеях и предупреждениях для идей, которые кажутся интуитивно правильными, но на практике могут оказаться плохими.
