Объединить своё облако с внешним сервисом
Если вы пробовали создавать своё приватное облако на домашнем сервере, например, используя Nextcloud, то наверняка сталкивались с проблемами из-за того, что затруднительно обеспечить его работу всё время: иногда случаются аварии у провайдера, иногда отключают электричество, то есть, даже если свой сервер будет достаточно надёжен, если будет правильно организовано резервное копирование, есть ряд проблем, которые не дадут достичь той надёжности, которую дают облачные решения, предлагаемые крупными компаниями.
С другой стороны, как мы сейчас видим, дата-центры — уязвимая цель, и если учитывать риск атаки беспилотников, то свой сервер может быть даже лучшим решением.
Понятно, что кто-то захочет свести суть проблемы к конкретным решениям конкретного человека, но всю историю человечества технологии используются в том числе и во вред людям, и нельзя было бы предполагать, что с беспилотниками было бы иначе: их могли освоить террористы (и они наверняка их осваивают), по нам могли нанести массовый удар беспилотниками наши стратегические противники (а мы были бы не готовы), в общем, угроза возникла потому, что технологии достигли определённого уровня, и вопрос скорее был в том, успели бы мы эту угрозу осознать и адаптироваться, или затянули с этим и оказались бы беспомощными в тот момент, когда эту технологию стали бы использовать против нас.
То есть, надо понимать, что мир поменялся, и что, в частности, облака не могут обеспечить ту надёжность, что раньше. И такие изменения будут снова и снова, и ко всем им нужно быть готовыми.
Наверное в нынешней ситуации лучшим вариантом будет не свой сервер, не облако, а гибрид: синхронизировать свой сервер с облаком. Для иллюстрации рассмотрим личное облако на основе Nextcloud. У данной системы есть возможность использовать внешнее хранилище, которое может быть просто каталогом на том же компьютере, а этот каталог можно синхронизировать с облаком, причём синхронизация может идти в обе стороны, например, при помощи приложения rclone в режиме bisync. То есть, можно работать с файлами на своём сервере, в том числе через Интернет (если получить доменное имя и статический белый IP-адрес), можно получить доступ к тем же файлам через облако (современные облачные провайдеры обычно дают возможность для доступа к файлам через WebDAV), и изменения в одном месте будут синхронизированы с изменениями в другом. Отключили электричество там, где стоит свой сервер — работаем через облачного провайдера, а потом всё синхронизируется, произошла авария в датацентре — файлы есть на своём сервере. Более того, иногда люди сталкиваются с тем, что их файлы в облаке теряются (например, забыли оплатить), но в случае гибридной системы, если настроено резервное копирование, то даже если провайдер по какой-то причине что-то удалит, останутся свои резервные копии.
Рекомендуемые опции rclone bisync
--check-access — проверка доступности обеих сторон через контрольные файлы RCLONE_TEST. При ошибке синхронизация прерывается.
--max-delete 5 — блокировка синхронизации при удалении более 5% файлов. Для максимальной защиты: --max-delete 0 (запрет любых обнаруженных удалений).
--resilient — повторные запуски после временных ошибок без обязательного --resync.
--recover — восстановление после прерванной синхронизации без обязательного --resync.
--retries 3 --retries-sleep 30s — три повторные попытки с интервалом 30 секунд (совместно с --resilient).
--backup-dir1 /srv/backup/bisync — сохранение удаляемых и заменяемых локальных файлов в отдельном каталоге.
--backup-dir2 cloud:backup/bisync — аналогичное резервирование файлов облака.
Важно: контрольные файлы RCLONE_TEST необходимо предварительно создать на обеих сторонах. Каталоги резервирования должны находиться вне синхронизируемых деревьев. Опции не заменяют независимые резервные копии.
--check-access \
--max-delete 5 \
--resilient \
--recover \
--retries 3 \
--retries-sleep 30s \
--backup-dir1 /srv/backup/bisync \
--backup-dir2 cloud:backup/bisync