С какими проблемами придется столкнуться при создании сервиса облачного бэкапа?
Хочу начать пет-проект облачного бэкапа, но предполагаю, что он может получить и коммерческое развитие.
Хочется сразу понимать, какие вопросы/запросы могут быть у пользователей и с какими проблемами придется столкнуться.
Первое, про что я подумал, это шифрование бэкапов.
Дабы пользователь был уверен, что админы не могут расшифровать его бекапы, данные можно расшифровывать паролем пользователя. Но, получается, что в таком случае, при смене пароля, все бекапы надо перешифровывать? Или есть другое решение?
Шифровать проблемы это скучно и просто. Не указано бэкап чего, ибо бекары бывают разные. Ну и сложность самая большая - делать бекар без остановки вычислительных ресурсов и без дополнительной нагрузки. Это обязательное требование сегодня
Антон Иванов, можете почитать issues и хотелки пользователей. Это и будет ответом на ваши вопросы. Ну и посмотреть как сделано в готовых системах не помешает.
Михаил Васильев, Да, спасибо, issues уже смотрю. А на реализацию отдельных решений буду смотреть после того, как сам реализую. Чтобы не быть под влиянием.
пет-проект облачного бэкапа - первая проблема, нехватка дискового пространства, за которое придётся платить огромные деньги, если хочешь чтобы и место было и скорость соединения с сервером в интернете на уровне.
что в таком случае, при смене пароля, все бекапы надо перешифровывать? - это только пол беды, во первых шифровать не паролем а идентификатором пользователя, только так, чтоб он не менялся при смене пароля, логина и так далее.
Но что будет когда пользователь попросту забудет/потеряет пароль или логин, или его украдут и удалят все данные????? нужно будет делать бэкап бэкапов??? и сколько таких ревизий нужно будет делать на одного пользователя??? и сколько это потребует дискового пространства????
Вопросов очень много, задай сколько мощностей обслуживает Google Drive или Яндекс Диск, у них нет шифрования :)
Дабы пользователь был уверен, что админы не могут расшифровать его бекапы, данные можно расшифровывать паролем пользователя.
Нет.
В этом случае пользователь не может быть уверен в том что админы не могут расшифровать, ибо они могут.
Неважно каким вы паролем шифруете - если пароль у вас есть - вы можете расшировать. Пользователь может быть уверен в том что вы не расшифруете, только если шифрует сам.
Организаторы площадок для хранения бэкапов вообще шифрование на стороне пользователя не любят, ибо это не позволяет им оптимизировать данные. Например ту же дедупликацию уже невозможно будет использовать.
А посему нельзя использовать дедупликацию? Вычисляем хэш файла, который не будет зависеть от пароля и храним на сервере. При создании следубщего бэкапа сверяем с данными с сервера и понимаем, менялся ли файл
Потому что шифрованный файл это набор данных близкий к случайному. Вероятность возникновения больших одинаковых блоков данных в двух шифрованных файлов стремиться к нулю, следовательно эффективность дедупликации будет около нуля.
При создании следубщего бэкапа сверяем с данными с сервера и понимаем, менялся ли файл
Зачем такая информация? Какая разница менялся файл или нет? И какое это имеет отношение к дедупликации?
Возможно я неправильно понял, что за дедупликация имеется в виду :) я ж не профи в создании бэкапов. Я так понял, что это возможность не хранить один и тот же файл в двух бэкапах, если этот файл не менялся
Антон Иванов, Дедупликация это хранения дублирующихся элементов в одном экземпляре.
Вы делаете бэкап системы. В системе есть файл notepad.exe он будет записан в бэкап.
Потом вы делаете бэкап другой системы, он тоже будет записан в бэкап, но на диске не сохранится, ибо такая же информация уже есть в хранилище.
Только это работает не на уровне файлов, а на уровне блоков - одинаковые куски информации находятся даже в разных файлах.
У меня есть 50компьютеров, их надо бэкапить, как данные таки и саму систему, чтобы быстро восстановить.
В итоге 50 системных дисков с ОС Windows идут в бэкап.
На системном диске обычно 60-90Гб информации. Допустим в среднем 80.
В итоге для хранения бэкапов системы всех 50компьютеров нужно 80Гб *50=4000ГБ =4террабайта.
А у меня бэкап системы всех 50компьютеров хранится на диске размером 1террабайт, и занимает на нем меньше половины места.
Потому что работает дедупликация.
Есть файл базы данных 1с - размером 5Гигабайт
Делаем бэкап - 5Гигабайт
На следующий день файл бд изменился. Делаем опять бэкап, дедупликатор ищет блоки которые изменились и записывает в бэкап, остальные блоки он не трогает, они уже есть в бэкапе.
В итоге второй бэкап - 200мегабайт.
И так каждый день.
Вместо того чтобы пихать в архив весь файл, туда идут только измененные части.
Довольно заметная разница - вместо 5гигабайт -200мегабайт.
Антон Иванов, Если интересна тема дедупликации -
Она штатно идет на любом Windows Server, и даже можно включить на любой Windows свежей, правда с нарушением лицензии.
Проще всего воспользоваться замечательной свободной утилитой - zpaq это архиватор и дедупликатор в одном флаконе. Дедупликация реализована не хуже чем в майкрософт.
Простой
