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-плейбуке. Но и руками делается тоже быстро.

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