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