26.05.2026 15:30
Предупреждение для тех, кто использует облачные хранилища файлов, как основные.
Предупреждение для тех, кто использует облачные хранилища файлов, как основные. Как я уже не раз говорил, у меня используется Яндекс.Диск, но исключительно, как резервное хранилище. Основное у меня дома на NAS. Оно копируется ещё в одно место локально, и в облако. Объём основной полезной информации в районе 1,5 ТБ и это ~175 тыс. файлов.
Я провёл несколько экспериментов с облачным хранилищем, о которых хочу рассказать. Если у вас там хранится важная информация, то рекомендую обратить на это внимание.
1️⃣ Взял чистую систему, установил туда клиент Яндекс.Диска и запустил синхронизацию, чтобы проверить, сколько времени займёт загрузка облачного архива. Канал в интернет - 100 мегабит, размер файлов в облаке - 1,1 ТБ. В идеальных условиях это должно качаться 25-30 часов. У меня в итоге ушла неделя. Большую часть времени клиент что-то обрабатывал и не занимал канал, и компьютер тоже особо не нагружал. Он не был узким местом. Если храните там какие-то важные бэкапы, которые нужно будет быстро забрать в случае аварии, имейте ввиду, что не факт, что получится это сделать.
2️⃣ Взял примерно полугодовалую локальную копию и сравнил MD5 хэши с тем, что скачалось из облака. Примерно у 500 файлов хэши не совпали, при полном совпадении всех остальных атрибутов. То есть без сверки хэшей разницу не заметить. Бегло проверил несколько из них. Это были фотки. На них наглядно видно повреждения. Проблемы были именно в облачных файлах. Где они побились - не понятно. Может во время хранения, может во время загрузки в облако или скачивания.
3️⃣ Примерно у 80% файлов были неверные даты создания. Сравнивал с основным хранилищем. Когда и почему они изменились - не знаю. Раньше никогда не обращал на это внимание. Размеры файлов одинаковые, а даты - разные. Это не сказать, что критично, но может создавать неудобства. И не понятно, как исправить, кроме как заливать туда заново все файлы с изменёнными датами.
4️⃣ Отдельно добавлю, о чём уже ранее писал. У меня был случай, когда часть файлов в Яндекс.Диске пропала. Заметил не сразу и только благодаря локальным копиям с большой глубиной хранения.
Я не знаю, как обстоят дела у других облаков, но мне кажется, плюс-минус примерно так же. Стоимость хранения везде относительно низкая для такого рода услуг. Обеспечивать надёжный сервис за эти деньги вряд ли получится, поэтому могут случаться накладки. Используйте их как один из дополнительных бэкапов, но не как основное хранилище.
У меня Яндекс.Диск используется как для хранения бэкапов, так и для совместного хранилища для разных устройств, которые только частично синхронизируют информацию с ним. Но всегда есть отдельный компьютер или виртуалка, которая синхронизируют себе полную копию облачных данных, и с этой копии делается инкрементный бэкап с глубиной хранения 180 дней.
Все сравнения и синхронизации обычно делаю с помощью программы Goodsync.
#fileserver
Я провёл несколько экспериментов с облачным хранилищем, о которых хочу рассказать. Если у вас там хранится важная информация, то рекомендую обратить на это внимание.
1️⃣ Взял чистую систему, установил туда клиент Яндекс.Диска и запустил синхронизацию, чтобы проверить, сколько времени займёт загрузка облачного архива. Канал в интернет - 100 мегабит, размер файлов в облаке - 1,1 ТБ. В идеальных условиях это должно качаться 25-30 часов. У меня в итоге ушла неделя. Большую часть времени клиент что-то обрабатывал и не занимал канал, и компьютер тоже особо не нагружал. Он не был узким местом. Если храните там какие-то важные бэкапы, которые нужно будет быстро забрать в случае аварии, имейте ввиду, что не факт, что получится это сделать.
2️⃣ Взял примерно полугодовалую локальную копию и сравнил MD5 хэши с тем, что скачалось из облака. Примерно у 500 файлов хэши не совпали, при полном совпадении всех остальных атрибутов. То есть без сверки хэшей разницу не заметить. Бегло проверил несколько из них. Это были фотки. На них наглядно видно повреждения. Проблемы были именно в облачных файлах. Где они побились - не понятно. Может во время хранения, может во время загрузки в облако или скачивания.
3️⃣ Примерно у 80% файлов были неверные даты создания. Сравнивал с основным хранилищем. Когда и почему они изменились - не знаю. Раньше никогда не обращал на это внимание. Размеры файлов одинаковые, а даты - разные. Это не сказать, что критично, но может создавать неудобства. И не понятно, как исправить, кроме как заливать туда заново все файлы с изменёнными датами.
4️⃣ Отдельно добавлю, о чём уже ранее писал. У меня был случай, когда часть файлов в Яндекс.Диске пропала. Заметил не сразу и только благодаря локальным копиям с большой глубиной хранения.
Я не знаю, как обстоят дела у других облаков, но мне кажется, плюс-минус примерно так же. Стоимость хранения везде относительно низкая для такого рода услуг. Обеспечивать надёжный сервис за эти деньги вряд ли получится, поэтому могут случаться накладки. Используйте их как один из дополнительных бэкапов, но не как основное хранилище.
У меня Яндекс.Диск используется как для хранения бэкапов, так и для совместного хранилища для разных устройств, которые только частично синхронизируют информацию с ним. Но всегда есть отдельный компьютер или виртуалка, которая синхронизируют себе полную копию облачных данных, и с этой копии делается инкрементный бэкап с глубиной хранения 180 дней.
Все сравнения и синхронизации обычно делаю с помощью программы Goodsync.
#fileserver