Fullstack Founder

Метка: бэкап

  • Файлы теперь лежат в ведрах

    Файлы теперь лежат в ведрах

    Раньше, когда пользователь загружал картинки на сайт, картинки сохранялись в папку на том же сервере. У популярных сайтов диски быстро заполнялись и требовалось следить за этим. Далее серверы начали упираться в ограничения на количество файлов в папке и на количество папок на диске.

    В 2006 Амазон запустили Simple Storage Service (S3) — сервис с простым хранением файлов в облаке, призванный решить все эти вопросы. Через API загружаем файл, сервис генерирует ссылку. Файл загружается в вёдро (bucket), а не на диск. Вёдра не имеют ограничений как у папок и могут быть распределены по разным серверам.

    Сейчас S3-сервис можно создать на многих хостингах в пару кликов. Также можно развернуть своё S3-хранилище с помощью Open Source, например MinIO.

    Для чего это нужно нам сейчас на практике?
    — Загружать и хранить бэкапы — первое с чего обычно начинают.
    — Хранить файлы отдельно от нод, обрабатывающих запросы.
    — Отдавать статические файлы сайта (картинки, скрипты, файлы для скачивания) с отдельного сервиса.
    — Избегать ситуации с переполненным диском на сервере за счёт переноса всех больших файлов в S3.
    — Организовывать безразмерные хранилища файлов на терабайты с открытым и закрытым доступом.
    — Для S3-хранилищ есть библиотеки на всех популярных языках.
    — Все S3-совместимые хранилища работают по образцу Amazon S3, поэтому ко всем хранилищам нужна одна библиотека.
    — Для разработки в docker-compose удобно использовать образ MinIO.

    Может тарифицироваться:
    — Стоимость хранения в гигабайтах.
    — Стоимость трафика загрузки в облако (чаще всего бесплатно)
    — Стоимость трафика выгрузки из облака.
    — Запросы к файлам.
    — Хранение старых версий файла (если работает с версионированием).

    Для большинства проектов переход на S3 — шаг на пути к масштабированию и большим нагрузкам. Но нужно внимательно считать сценарий использования — может оказаться значительно дороже традиционного способа.

  • Продублируй важные системы

    Продублируй важные системы

    Все критические системы должны быть продублированы. За последние годы я видел, как останавливаются и ломаются критические системы у очень больших сервисов — отзыв лицензии у Точки и Киви, сбои в эквайринге от Сбера и Юкассы, упавший на две недели СДЭК, почта от Юнисендера…

    Поэтому, напоминаю себе и вам:
    — У бизнеса должно быть открыто два расчетных счёта в разных банках. Резервный счёт может ничего не стоить, но спасти много нервных клеток в случае конфликта с основным банком. А ещё у банков иногда отзывают лицензию.
    — У бизнеса должно быть два юридических лица, например, ИП и ООО одновременно. Если одно из юр лиц имеет спор с налоговой, то второе может подхватить хозяйственную деятельность.
    — В онлайн-сервисе должно быть два эквайринга. Особенно, если это банковский эквайринг, а не агрегатор — агрегатор может переключить шлюз на другой банк.
    — Онлайн-касс тоже должно быть хотя бы две.
    — У интернет-магазина должно быть две службы доставки.
    — Как я вчера выяснил, должно быть две службы для email и sms рассылок, если они для вас критичные. Если не работает отправка сообщений, то покупатели не могут попасть в личный кабинет.
    — Правильно иметь копию инфраструктуры в другом дата-центре. Хотя бы бэкапы хранить отдельно и иметь возможность быстро поднять все сервисы.
    — Домен и DNS лучше держать отдельно от серверов. Потому что, если выключился хостинг, нужно иметь возможность перенаправить трафик в другой дата-центр.
    — Можно заранее купить второй домен и использовать его в рекламе или для корпоративных нужд.
    — Крупные интернет-магазины держат два агентства по трафику, запуская рекламные кампании по очереди. Или даже просто выплачивают второму подрядчику резервную абонентскую плату и держат деньги на балансе рекламного кабинета.
    — Нужно держать бэкапы всего, хранить минимум в двух экземплярах в разных локациях. И проверять, что бэкапы рабочие.

    Всего не предусмотришь, но некоторые моменты настолько очевидны, что на чёрного лебедя их не спишешь. Технически будет виноват поставщик, но проблемы и убытки будут у тебя.

  • Безопасность веб-сервера

    Безопасность веб-сервера

    Безопасность сайта начинается с уменьшения площади возможной атаки.

    Чеклист, который выработал и применяю у себя:
    — IP-адрес реального сервера никогда не был прописан в DNS домена. В DNS попадает proxy или балансер — от Cloudflare, Fortes, Qrator или вашего другого сервера.
    — Отключена возможность зайти под root пользователем. Вначале сделали нового пользователя, дали ему sudo-права, потом запретили вход из-под root.
    — SSH-логин возможен только по ключу, пароли отключены совсем.
    — SSH работает на нестандартном порте — 22-й слишком очевиден, меняем.
    — Стоит и настроен firewall. Закрыты все порты, кроме нужных: 80 и 443 для сайта, порт для SSH, порт под метрики для мониторинга. Мой выбор ufw, его вполне хватает всё перекрыть.
    — Установлен fail2ban — чтобы не донимали сервер брутфорсом.
    — Операционная система и системные программы периодически обновляются.
    — На сервере отключена возможность отправки почты. Совсем. Если взломают — сервер не станет рассадником спама и не нужно будет его IP вычищать из блеклистов. Вся почта отправляется через внешний SMTP.
    — Не ставим или удаляем FTP — протокол устаревший и через него часто ломают серверы.
    — Во всех папках для загрузки файлов через сайт стоит запрет на выполнение кода. В nginx и apache прописывается запрет. WordPress и Битрикс чаще всего ломают именно так — заливают исполняемый PHP-файл в загрузки и запускают по прямой ссылке.
    — PHP позволяет запретить вызов некоторых функций. Вам точно нужен eval()?
    — В идеале — код движка размещён выше корня веб-сервера. Так сделано во всех «взрослых» фреймворках. WP и Битрикс требуют ухищрений, но тоже можно кое-что сделать.
    — Движок обновлён до свежей версии. Тут у клиентов зачастую беда, потому что поддержкой не занимаются.
    — Код сайта в git. Всегда можно посмотреть и откатить любые заражения за одну минуту. git reset --hard и всё почистили.
    — Минимум раз в сутки делается бэкап базы данных и загруженных файлов.
    — На сервере установлены и периодически запускаются руткит-сканеры.

    Это базовые действия. Опытные сисадмины добавят ещё пару десятков пунктов.
    У меня большая часть этих действий происходит автоматически, потому что прописана в ansible-плейбуке. Но и руками делается тоже быстро.

    А что я забыл и вы бы добавили в этот чеклист?