Как сделать максимально автономный сервер?

Есть требование захостить некоторое количество информации так, чтобы она не потерялась и была доступна из интернета неограниченное количество времени. Желательно без действий по поддержанию, или с минимальными действиями: может случиться так, что через десять лет поддерживать это будет уже некому, а сохранить хочется.

Можно взять "вечный сервер", например, нашел эти:
vdsi na(dot)ru/eternal-server
etern alhost(dot)net/vps
seop ulses(dot)ru/kak-poluchit-besplatniy-vps-vds-server-navsegda/
clou datcost(dot)com/dedicated-servers

Можно даже несколько, и настроить зеркала через DNS. С доменом понятно, что ничего не сделать, кроме как оплатить на максимум, на 10 лет. А что можно сделать по технологиям хостинга самого?
Понятно, что идеальное решение — это хостинг статики, но мне кажется, это не получится. Как можно обеспечить максимальную отказоустойчивость?
Сразу отпадают все современные технологии, типа докера: через десять лет он изменится настолько, что не будет иметь отношение к той версии, что стоит на сервере.
  • Вопрос задан
  • 1152 просмотра
Пригласить эксперта
Ответы на вопрос 10
ValdikSS
@ValdikSS
1. Никаких «вечных серверов». Даже как-то неловко разъяснять такое. «Вечный сервер» — маркетинговый ход, фактически мошенничество, который закончится, как только компания изменит условия/реорганизуется/закроется. Следует читать как «ну, проработает года три, а далее — неизвестно».

2. Непонятно, какого рода у вас информация, и что именно вы понимаете под словом «захостить», также непонятен критерий автономности. Разместить информацию в публичный доступ? Должна ли она индексироваться? Нужен ли для неё контроль доступа? По какому протоколу она должна быть доступна? Она будет нужна только вам через 10 лет, или кому-то еще? Это лицензированный контент, который могут удалить по DMCA (фильмы, сериалы, музыка)? Это персональные данные (сливы баз данных)? Информация популярна и/или востребована на данный момент? Есть вероятность, что она будет сравнительно востребована через 10 лет? Информация каталогизирована? Информация тематическая (например, архив, посвященный конкретной теме, области науки и т.п.)? Важно ли удобство и скорость доступа к информации?
Технологий много, но они все разные, с разными назначениями. Ответы на перечисленные вопросы необходимы, чтобы отбросить неподходящие и подробно рассмотреть подходящие.

3. Если информация публична и востребована, и будет востребована через 10 лет, то следует использовать DC++, BitTorrent + веб-хранилища с прямыми ссылками на файл, добавив ссылки в .torrent-файл, в виде webseed.
Bittorrent существует с 2006 года, популярен, клиенты есть под все ОС, совместимость и надёжность отличные.
DC++ всё еще имеет популярность. Основное преимущество перед Bittorrent: возможность поиска файла по его имени или названию директории, возможность лёгкого обновления и дополнения информации (нет привязки к «каталогу» в виде .torrent-файла)

Если информация конфиденциальна или требует контроля доступа, и у вас и кого-либо другого не будет возможности как-либо поддерживать её в течение 10 лет (я не знаю вашу ситуацию, поэтому предположим, что вам грозит 10-летний тюремный срок), то, возможно, есть смысл оплатить облачное хранилище от крупных компаний (Google, Yandex, Microsoft, Apple) на 10 лет вперед. Это не даёт никаких гарантий, но считаю такой вариант более надёжным, нежели хостинг общего плана (и особенно VPS).

Если информации немного, она не защищена авторскими правами, каталогизирована и полезна, можно банально разместить её на давно существующих бесплатных хостингах, вроде Ucoz, Google Sites, Neocities, загрузить на Bitbucket, Github, Sourceforge (последний поддерживает хранение больших файлов, которые можно скачать по прямой ссылке, вполне подойдёт в качестве webseed для торрента, к слову).

Если не боитесь попробовать развивающиеся, но еще не устоявшиеся технологии, присмотритесь к IPFS. Он работает по принципу Bittorrent, но позволяет получать доступ к информации через HTTP, а также поддерживается крупными игроками в лице Cloudflare, у которой есть шлюз из интернета в IPFS: https://cloudflare-ipfs.com/
Я держу несколько статичных сайтов с собственными доменами в IPFS, на домашнем компьютере, за шлюзом Cloudflare. Преимущества: все плюсы BitTorrent, возможность доступа как к сайту (в т.ч. на своём домене), индексация поисковиками, есть сервисы по долгосрочному платному хранению файлов (eternum.io, pinata.cloud), возможность лёгкого обновления информации. Недостатки: работает всё ещё достаточно медленно и нестабильно, только статичные сайты.

4. Судя по вашему комментарию выше, у вас всего 100 ГБ медиафайлов. Это вообще ерунда. Если они публичны и представляют ценность хотя бы для узкого круга людей, можете захостить их у меня, через проект Schare: https://valdikss.org.ru/schare/
Мой критерий автономности — максимальная независимость от сторонней инфраструктуры, поэтому файлы хостятся на домашнем сервере, а раздаются в сетях децентрализованного файлообмена.
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Я не специалист, но если это должно хоститься долго, об этом должна заботиться сама информация в таком материале: давать понимание читателям своей ценности и просить рехостинга/"зеркалирования" ими для выживания контента.

Если информация ценна для людей - она сможет долго выживать таким способом.

Главное - написать внутри: как лучше её рехостить так, чтобы другие могли её найти и прочитать, и почему это важно.

По факту, это "вирусный" репост.

Что важно сейчас: webarchive, github'ы и тематические wiki-сайты. Вот туда первым делом залить.

Можно также и на бесплатных популярных cms-хостингах тоже сделать сайты, чтобы можно было скачать всё одним файлом и кэш страниц в поисковиках остался.
Ответ написан
Sanes
@Sanes
Само ничего работать не будет. Тем более вечно.
Неизвестно что завтра будет, а вы строите планы на 10 лет.
Ответ написан
@Tabletko
никого не трогаю, починяю примус
Никак.
доступна из интернета неограниченное количество времени
Требует неограниченное количество денег.
Ответ написан
Комментировать
paran0id
@paran0id
Умный, но ленивый
Раскидать сервис на несколько надёжных хостингов с хорошей репутацией (среди перечисленных таких нет), проплатить на 10 лет вперед (или привязать счет с автоматической оплатой). Сделать балансировщик между ними. Но всё равно, за 10 лет обязательно что-то случится. Если у вас не просто статические данные - добавьте туда вероятность обраружения 0day-дырок, из-за которых ваш сервис попадет в ботнет и будет справедливо отключен. Проще, мне кажется, заключить договор на поддержку этого сервиса. Надежнее и, возможно, дешевле.
Ответ написан
SignFinder
@SignFinder
Wintel\Unix Engineer\DevOps
Идеальных и безопасных ОС нет. Поддержание ОС в актуальном состоянии автоматически на данном этапе не возможно.
Через 10 лет без поддержки ваш сервер превратится в одну сплошную дыру безопасности, в которой не будет места вашей информации.
Ответ написан
Комментировать
gbg
@gbg
Любые ответы на любые вопросы
Хостить образ виртуалки. А внутри виртуалки можно насовать что угодно, хоть докер.
Ответ написан
Комментировать
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Да никак это не обеспечить. Ни одна виртуалка не работает со 100% доступностью, а это значит что она перезапускается и что там что-то может обновиться. Или, в редких случаях, закончатся ресурсы для запуска машины в датацентре.

С хостингом статики примерно та же история - может поменяться что угодно, например, правила использования сервиса. Или сервис закроют или еще что.

В общем 100% вероятности не даст никто.

Ну и еще, доступность это определенное число в % из девяток. Например, 99.99%. Добавление каждой девятки дополнительно, на вскидку, это добавление пары нулей к стоимости проекта. Делаем выводы
Ответ написан
Amazon aws
Ответ написан
Комментировать
CityCat4
@CityCat4
//COPY01 EXEC PGM=IEBGENER
Как можно обеспечить максимальную отказоустойчивость?

Никак.

Даже виртуалка со статикой требует обслуживания - например, место кончится - логи засрут все. У меня есть пара примеров, когда системы работают больше десятка лет без обновления, но тем не менее их все-таки периодически обслуживали и переносили с сервера на сервер.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы