FirstVDS Хостинг

Ну как вы там? Держитесь? Помощь рядом. Ловите лучи бодрости и хорошего настроения от ребят и девушек из FirstVDS. Удалёнка наше все!


А пока вы немного отвлеклись от работы или вынужденного отдыха, в котором все дни как День сурка, рассказываем, что интересного произошло у нас в апреле. Тут и запуск сервиса CLO, и бесплатные серверы, и свежеиспечённые статьи с последними новостями (не про коронавирус).

Так что устраивайтесь поудобнее. И поехали!

Статьи и инструкции
Нагрузка на сервер: как проверить и что исправить
Нагрузить сервер по самое «не хочу» и создать проблемы на пустом месте может не только массовый исход людей в онлайн во время пандемии. Причины бывают разные.

Если наблюдаете проблемы в работе приложений, загрузке файлов или при подключении к серверу, наш совет: начните с мониторинга. Когда поймёте, где и что пошло не так, разберётесь и с остальным. А поможет в этом наша подборка. Составили, что была под рукой, а то мало ли что…

• Нагрузка на сервер: определение причин
• Диагностика ресурсов сервера
• Статистика нагрузки на сервер, atop
• Уменьшение нагрузки на VDS
• Что делать, когда осталось мало места на диске
• Что делать, когда на сервере кончаются файловые дескрипторы (inode)

Браузер на страже API-запросов: строим безопасное общение фронтенда с бэкендом
Разработчики одностраничных приложений SPA так или иначе вынуждены сталкиваться с ограничениями браузерной безопасности. С особенным подозрением браузер присматривается к тем, кто держит фронтенд и бэкенд на разных доменах — правила строже, санкции жёстче, а работать надо. О том, как сделать так, чтобы фронтенд-сторона могла беспрепятственно и, что тоже важно, безопасно общаться с бэкенд API-сервером, в статье нашего разработчика Сергея на Хабре.
habr.com/ru/company/first/blog/497342/

Новый сервис CLO

Ура! Есть повод похвастаться. В апреле мы не только перешли на удалёнку, продолжая поддерживать работу всех систем и услуг, но и запустили новый сервис CLO. Это привычные виртуальные серверы с расширенными облачными возможностями: почасовая оплата, плавающие IP, переключаемые диски.
Если вам нужна гибкая и отказоустойчивая инфраструктура — CLO поможет её построить, решая задачи, которые не под силу обычному VDS. Чтобы узнать больше о сервисе, посмотреть тарифы и получить доступ в Личный кабинет, велкам по ссылке на сайт CLO.
clo.ru

И это еще не всё. Руководитель команды разработки поделился, с какими трудностями его ребятам пришлось столкнуться во время работы над сервисом. История в словах и картинках, приправленная киберпанком, уже в нашем блоге на Хабре.

habr.com/ru/company/first/blog/493606/

Уязвимости и релизы месяца
Ещё одна хорошая новость — уязвимостей в этом месяце нет. По крайней мере, тех, что были бы удостоены чести попасть в дайджест. Но расходиться рано. Буквально пара слов о релизе WP.

Релиз Wordpress 5.4
В апреле стала доступна версия 5.4 системы управления контентом сайтов WordPress. Основные изменения затронули редактор блоков: их выбор стал больше, а возможности настроек — шире. Чтобы CMS работала корректно, используйте рекомендованные версии ПО: PHP 7.3+, MySQL 5.6 или MariaDB 10.1+. Подробнее об изменениях на linux.org

Инициатива #SaveFirst в условиях COVID-19
Для многих людей апрель оказался непростым временем. И чтобы улучшить их жизнь в период самоизоляции, некоторые компании стали помогать бесплатно. Чтобы поддержать их начинания, мы запустили инициативу #SaveFirst. Благодаря ей образовательные, досуговые и другие социально значимые проекты, готовые помогать людям бесплатно, могут получить у нас виртуальные серверы, просто заполнив заявку на сайте.
firstvds.ru/savefirst
Надеемся, что скоро жизнь вернётся в привычное русло, а пока помощь ближнему — то, что позволяет всем нам оставаться людьми.

Сперва немного предыстории.
Осенью прошлого года мы проводили закрытое бета-тестирование нового сервиса, разработанного нашей командой. Так сказать, первый пробный запуск, после которого собрали фидбэк, проанализировали его, а затем работали над улучшением продукта…

И сегодня мы хотим поделиться отличной новостью — запуск этого сервиса состоялся! Итак, знакомьтесь.

Сервис CLO — это уже привычные для вас виртуальные серверы, но с расширенными облачными возможностями. Мы предлагаем готовое и доступное по цене решение, с помощью которого легко создавать собственную отказоустойчивую IT-инфраструктуру, и решать задачи, непосильные для обычного VDS.


В вашем распоряжении виртуальные KVM-серверы, которые по умолчанию объединяются в серую локальную сеть, переключаемые диски и плавающие IP, которые при необходимости «перебрасываются» с одного сервера на другой. Можно использовать и статический IP-адрес. На выбор предлагаются три операционные системы: Ubuntu, Centos и Debian.

CLO — это универсальный инструмент и умная альтернатива VDS, выделенным серверам и собственным дата-центрам. С его помощью можно легко и быстро оптимизировать работу интернет-магазина, гибко управляя ресурсами в дни сезонных спадов или Чёрную пятницу. Или создать безопасную среду для разработки и тестирования, настроить удобную систему хранения или обработки данных, поднять сервисы для организации удаленной работы.

Преимущества сервиса

Экономит время
Удобный Личный кабинет, в котором легко разобраться. Управление ресурсами централизованно.

Сокращает расходы
Платите только за те ресурсы, которыми пользуетесь. Оплата считается по часам.

Повышает надежность
Узлы кластера зарезервированы, а пользовательские данные дублируются, поэтому информация не потеряется.

Сервис построен на базе проверенных технологий: OpenStack, Tungsten Fabric, Ceph, которые позволяют создавать гибкие и отказоустойчивые облачные решения
clo.ru/

С ростом стажа работы в IT начинаешь замечать, что системы имеют свой характер. Они могут быть покладистыми, молчаливыми, взбалмошными, суровыми. Могут располагать к себе или отталкивать. Так или иначе, приходится «договариваться» с ними, лавировать между «подводными камнями» и выстраивать цепочки их взаимодействия.

Вот и нам выпала честь построить облачную платформу, а для этого потребовалось «уговорить» пару подсистем работать с нами. Благо, у нас есть «язык API», прямые руки и куча энтузиазма.

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

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

Был также и ряд требований:

• сервису нужен удобный личный кабинет;
• платформа должна быть интегрирована в существующую систему биллинга;
• программно-аппаратная часть: OpenStack + Tungsten Fabric (Open Contrail), которые наши инженеры научились достаточно хорошо «готовить».

О том, как собиралась команда, разрабатывался интерфейс личного кабинета и принимались дизайнерские решения, расскажем в другой раз, если у хабра-сообщества будет интерес.
Инструменты, которые мы решили использовать:

• Python + Flask + Swagger + SQLAlchemy — вполне стандартный Python набор;
• Vue.js для фронтенда;
• взаимодействие между компонентами и сервисами решили делать с помощью Celery поверх AMQP.

Предвосхищая вопросы о выборе в сторону Python, поясню. Язык занял свою нишу в нашей компании и вокруг него сложилась небольшая, но всё же культура. Поэтому было решено начинать строить сервис именно на нём. Тем более, что скорость разработки в таких задачах зачастую решает.

Итак, начнем наше знакомство.

Молчаливый Билл — биллинг
С этим парнем мы были знакомы давно. Он всегда сидел рядом и что-то молча считал. Иногда переправлял нам запросы пользователей, выставлял клиентские счета, управлял услугами. Обычный работящий парень. Правда, были сложности. Он молчалив, иногда задумчив и часто — себе на уме.


Биллинг — это первая система, с которой мы попытались подружиться. И первая же трудность встретилась нам при обработке услуг.

Например, при создании или удалении, задача попадает во внутреннюю очередь биллинга. Таким образом реализована система асинхронной работы с услугами. Для обработки своих типов услуг нам нужно было «складывать» свои задачи в эту очередь. И здесь мы столкнулись с проблемой: нехватка документации.


Судя по описанию программного API, решить эту задачу все же можно, но времени заниматься реверс-инжинирингом у нас не было, поэтому мы вынесли логику наружу и организовали очередь задач поверх RabbitMQ. Операция над услугой инициируется клиентом из личного кабинета, оборачивается в «задачу» Celery на бэкенде и выполняется на стороне биллинга и OpenStack’a. Celery позволяет достаточно удобно управлять задачами, организовывать повторы и следить за состоянием. Подробнее про «сельдерей» можно почитать, например, здесь.

Также биллинг не останавливал проект, на котором закончились деньги. Общаясь с разработчиками, мы выяснили, что при подсчете по статистике (а нам нужно реализовать именно такую логику) есть сложная взаимосвязь правил остановки. Но эти модели плохо ложатся под наши реалии. Также реализовали через задачи на Celery, забирая на сторону бэкенда логику управления услугами.

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

Еще одна проблема — молчаливость.

На часть запросов к API Билли молча отвечает «Ок». Так, например, было, когда мы делали зачисления обещанных платежей на время теста (о нем позже). Запросы корректно выполнялись и мы не видели ошибок.


Пришлось изучать логи, работая с системой через UI. Оказалось, что сам биллинг выполняет подобные запросы, изменяя scope на конкретного пользователя, например, admin, передавая его в параметре su.

В целом, несмотря на пробелы в документации и небольшие огрехи API, все прошло достаточно неплохо. Логи вполне можно читать даже при большой нагрузке, если понимать, как они устроены и что нужно искать. Структура базы данных витиеватая, но вполне логичная и в чем-то даже привлекательная.

Итак, подводя итоги, основные проблемы, которые у нас возникли на этапе взаимодействия, связаны с особенностями реализации конкретной системы:

• недокументированные «фичи», которые так или иначе нас затрагивали;
• закрытые исходники (биллинг написан на C++), как следствие — невозможность решить проблему 1 никак, кроме «метода проб и ошибок».

К счастью, у продукта есть достаточно развесистый API и мы интегрировали в свой личный кабинет следующие подсистемы:

• модуль технической поддержки — запросы из личного кабинета «проксируются» в биллинг прозрачно для клиентов сервиса;
• финансовый модуль — позволяет выставлять счета текущим клиентам, производить списания и формировать платежные документы;
• модуль управления услугами — для него нам пришлось реализовать свой обработчик. Расширяемость системы сыграла нам на руку и мы «обучили» Билли новому типу услуг.

Пришлось повозиться, но так или иначе, думаю, с Билли мы поладим.

Прогулки по вольфрамовым полям — Tungsten Fabric
Вольфрамовые поля, усеянные сотней проводов, прогоняющих через себя тысячи бит информации. Информация собирается в «пакеты», разбирается, выстраивая сложные маршруты, как по волшебству.


Это вотчина второй системы, с которой нам пришлось подружиться — Tungsten Fabric (TF), бывший OpenContrail. Ее задача — управлять сетевым оборудованием, предоставляя программную абстракцию нам, как пользователям. TF — SDN, инкапсулирует в себе сложную логику работы с сетевым оборудованием. Про саму технологию есть неплохая статья, например, тут.

Система интегрирована с OpenStack (о нём речь пойдет ниже) через плагин Neutron’a.


Взаимодействие сервисов OpenStack.

С этой системой нас познакомили ребята из отдела эксплуатации. Мы используем API системы для управления сетевым стеком наших услуг. Серьезных проблем или неудобств она нам пока не доставляет (за ребят из ОЭ говорить не возьмусь), однако были и некоторые курьезы взаимодействия.

Первый выглядел так: команды, требующие вывода большого количества данных на консоль инстанса при подключении по SSH просто «вешали» подключение, при этом по VNC все работало корректно.


Для тех, кто не знаком с проблемой, это выглядит достаточно забавно: ls /root отрабатывает корректно, тогда как, например, top «зависает» наглухо. К счастью, мы уже сталкивались с подобными проблемами. Решилось тюнингом MTU на маршруте от compute-нод до маршрутизаторов. К слову сказать, это и не проблема TF.

Следующая проблема ждала за поворотом. В один «прекрасный» момент магия маршрутизации исчезла, вот так просто. TF перестал управлять маршрутизацией на оборудовании.


Мы работали с Openstack с уровня admin и после этого переходили на уровень нужного пользователя. SDN, похоже, «перехватывает» скоуп пользователя, которым выполняются действия. Дело в том, что этот же админский аккаунт используется для связи TF и OpenStack. На шаге переключения под пользователя «магия» пропадала. Решено было завести отдельный аккаунт для работы с системой. Это позволило работать, не ломая функционал интеграции.

Силиконовые формы жизни — OpenStack
Силиконовое существо причудливой формы обитает недалеко от вольфрамовых полей. Больше всего оно похоже на ребенка переростка, который одним взмахом может раздавить нас, но явной агрессии от него не исходит. Оно не вызывает страха, но его размеры внушают опасение. Как и сложность того, что происходит вокруг.


OpenStack — ядро нашей платформы.

OpenStack имеет несколько подсистем, из которых активнее всего мы пока используем Nova, Glance и Cinder. Каждая из них имеет свой API. Nova отвечает за compute-ресурсы и создание instance’ов, Cinder — управление volume’ами и их снимками, Glance — image service, который управляет шаблонами ОС и метаинформацией по ним.

Каждый сервис запускается в контейнере, а брокером сообщений выступает «белый кролик» — RabbitMQ.

Эта система доставила нам больше всего неожиданных хлопот.

И первая проблема не заставила себя ждать, когда мы пытались подключить дополнительный volume к серверу. Cinder API наотрез отказывался выполнять эту задачу. Точнее, если верить самому OpenStack’у связь устанавливается, однако внутри виртуального сервера устройство диска отсутствует


Мы решили «пойти в обход» и запросили то же действие у Nova API. Результат — устройство корректно подключается и доступно внутри сервера. Похоже, что проблема возникает, когда block-storage не отвечает Cinder’у.

Очередная сложность ждала нас при работе с дисками. Системный volume не удавалось отсоединить от сервера.

Опять же, сам OpenStack «божится», что связь он уничтожил и теперь можно корректно работать с volume’ом отдельно. Но API категорически не желал производить операции над диском.


Здесь мы решили особенно не воевать, а изменить взгляд на логику работы сервиса. Уж коли есть instance, должен быть и системный volume. Поэтому пользователь пока не может удалить или отключить системный «диск», не удалив «сервер».

OpenStack — достаточно сложный комплекс систем со своей логикой взаимодействия и витиеватым API. Нас выручает достаточно подробная документация и, конечно, метод проб и ошибок (куда же без него).

Тестовый запуск
Тестовый запуск мы проводили в декабре прошлого года. Основной задачей ставили проверку в боевом режиме нашего проекта с технической стороны и со стороны UX. Аудиторию приглашали выборочно и тестирование было закрытым. Однако мы также оставили возможность запросить доступ к тестированию на нашем сайте.

Сам тест, разумеется, не обошелся без курьезных моментов, ведь на этом наши приключения только начинаются.

Во-первых, мы несколько некорректно оценили интерес к проекту и пришлось оперативно добавлять compute-ноды прямо во время теста. Обычный кейс для кластера, однако и тут были нюансы. В документации для конкретной версии TF указана конкретная версия ядра, на котором тестировалась работа с vRouter. Мы решили запускать ноды с более свежими ядрами. Как итог — TF не получил маршруты с нод. Пришлось экстренно откатывать ядра.


Другой курьез связан с функционалом кнопки «изменить пароль» в личном кабинете.

Мы решили использовать JWT для организации доступа в личный кабинет, чтобы не работать с сессиями. Так как системы разноплановые и широко разбросаны, мы управляем своим токеном, в который «заворачиваем» сессии от биллинга и токен от OpenStack’a. При изменении пароля токен, разумеется, «протухает», поскольку данные пользователя уже невалидны и его нужно перевыпускать.


Мы упустили этот момент из виду, а ресурсов, чтобы быстро дописать этот кусок, банально не хватило. Нам пришлось вырезать функционал перед самым запуском в тест.
На текущий момент мы выполняем logout пользователя, если пароль был изменен.

Несмотря на эти нюансы, тестирование прошло хорошо. За пару недель к нам заглянуло порядка 300 человек. Нам удалось посмотреть на продукт глазами пользователей, протестировать его в бою и собрать качественный фидбек.

Продолжение следует

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

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

Системы мы уже смогли уговорить. Билл послушно занимается подсчетом, выставлением счетов и запросами пользователей у себя в каморке. «Волшебство» вольфрамовых полей обеспечивает нас стабильной связью. И лишь OpenStack иногда капризничает, выкрикивая что-то вроде «'WSREP has not yet prepared node for application use». Но это совсем другая история…

Совсем недавно мы запустили сервис.
Все подробности вы можете узнать на нашем сайте.
clo.ru



OpenStack
docs.openstack.org/nova/latest/
docs.openstack.org/keystone/latest/
docs.openstack.org/cinder/latest/
docs.openstack.org/glance/latest/

Tungsten Fabric
docs.tungsten.io/en/latest/user/getting-started/index.html
www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

Сперва немного предыстории.
Осенью прошлого года мы проводили закрытое бета-тестирование нового сервиса, разработанного нашей командой. Так сказать, первый пробный запуск, после которого собрали фидбэк, проанализировали его, а затем работали над улучшением продукта…

И сегодня мы хотим поделиться отличной новостью — запуск этого сервиса состоялся! Итак, знакомьтесь.

Сервис CLO — это уже привычные для вас виртуальные серверы, но с расширенными облачными возможностями. Мы предлагаем готовое и доступное по цене решение, с помощью которого легко создавать собственную отказоустойчивую IT-инфраструктуру, и решать задачи, непосильные для обычного VDS.


В вашем распоряжении виртуальные KVM-серверы, которые по умолчанию объединяются в серую локальную сеть, переключаемые диски и плавающие IP, которые при необходимости «перебрасываются» с одного сервера на другой. Можно использовать и статический IP-адрес. На выбор предлагаются три операционные системы: Ubuntu, Centos и Debian.

CLO — это универсальный инструмент и умная альтернатива VDS, выделенным серверам и собственным дата-центрам. С его помощью можно легко и быстро оптимизировать работу интернет-магазина, гибко управляя ресурсами в дни сезонных спадов или Чёрную пятницу. Или создать безопасную среду для разработки и тестирования, настроить удобную систему хранения или обработки данных, поднять сервисы для организации удаленной работы.

Преимущества сервиса
Экономит время
Удобный Личный кабинет, в котором легко разобраться. Управление ресурсами централизованно.
Сокращает расходы
Платите только за те ресурсы, которыми пользуетесь. Оплата считается по часам.
Повышает надежность
Узлы кластера зарезервированы, а пользовательские данные дублируются, поэтому информация не потеряется.

Сервис построен на базе проверенных технологий: OpenStack, Tungsten Fabric, Ceph, которые позволяют создавать гибкие и отказоустойчивые облачные решения.


Посмотреть тарифы и зарегистрироваться в сервисе можно на сайте clo.ru
clo.ru

Чтобы облегчить жизнь людей во время самоизоляции, многие компании снизили цены на свои услуги, а некоторые и вовсе стали помогать бесплатно. Мы считаем, что это правильный путь, и не хотим оставаться в стороне, поэтому создали инициативу #SaveFirst.

Суть инициативы в том, что FirstVDS предоставляет бесплатно вычислительные мощности для размещения социально значимых проектов и онлайн-сервисов, работающих в таких направлениях, как:

• предоставление ПО для организации процессов удалённой работы;
• онлайн-образование;
• решения в области здравоохранения;
• организация культурного досуга.

Главное условие — доступ к сервисам также должен быть бесплатный.

Мы вынуждены вводить ограничение на количество серверов «в одни руки», но тариф можно выбрать любой — в том числе с максимальными параметрами.

Узнать подробные условия и подать заявку можно на сайте firstvds.ru/savefirst

Представьте, ваш ноутбук сломан, и всё, что на нём хранилось — безвозвратно исчезло. В том числе рабочий файл, над которым вы трудились несколько часов. Так однажды случилось с англичанином Адамом Джефферсоном. Все жизненно важные документы погибли вместе с ноутбуком. Он был в шоке — за секунду потерял 3 года трудов, а мог бы сохранить оригиналы где-нибудь ещё! Чтобы люди не повторяли его ошибку, в 2011 году он предложил сообществу американского сайта Reddit выделить специальный день для резервирования данных. Идею подхватили, и она получила международный охват.



День бэкапа — это напоминание всем, что пора сделать резервную копию, поэтому ставим запятую правильно и идём делать бэкап.

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

Бэкап против кибератак
31 марта выбрали Днём бэкапа неслучайно. Во-первых, чтобы не считать 1 апреля своим праздником. На сайте так и сказано. Во-вторых, раньше киберпреступность давала о себе знать именно 1 апреля. В этот день резко увеличивалось число вирусных атак на людей и компании. Теперь это случается гораздо чаще. В 2019 году эксперты по кибербезопасности посчитали, что каждые 14 секунд в мире фиксируется 1 кибератака. В 2020 году цифра вырастет — преступники совершенствуются в инструментах и исполнении.

Больше всех от киберпреступности страдает малый и средний бизнес. В прошлом году 72% компаний пережили хотя бы одну атаку. Вирусы выводят из строя ПО, злоумышленники воруют персональные данные клиентов и конфиденциальные файлы. Восстановление после серьёзных атак приводит к огромным убыткам.

Так что откладывать резервное копирование на День бэкапа не стоит. Полные копии эксперты по безопасности советуют делать раз в неделю. А если система обновляется много раз за день, как в интернет-магазинах, где ежедневно тысячи клиентов делают свои заказы, то делать бэкапы нужно каждый день.

Бэкап против человеческой ошибки
Уничтожить информацию могут не только злоумышленники, но и сотрудники компании. Даже ее владельцы. Вы слышали о Марко Марсале, который «удалил» свою хостинговую компанию? А всего-то ошибся в строчке кода: стёр исходный код и все базы данных. Резервных копий у него не оказалось — он почистил всё, что было на сервере. Страшно представить, на что был готов Масала ради резервной копии в тот момент.

Опытный технический специалист перед тем, как вносить изменения в систему обязательно сделает бэкап. И правильно. Даже профессионалы ошибаются, а правильно сделанный бэкап — поможет ошибку исправить.

Где делать бэкапы
Вариантов хранения не так много:

• локальное хранение на диске рабочего сервера
• облачное хранение
• бэкапы у разных хостинг-провайдеров

Локальное хранение на диске рабочего сервера
Самый простой вариант, но, по опыту Марсалы, не самый надёжный. Вся важная информация копируется и хранится там же, где и основные данные. Поможет только, если нужно восстановить удалённый файл, не более того. Но объект DDoS-атак, вирусов и действий злоумышленников — не конкретный файл, а вся инфраструктура и сервер. Локальное резервное копирование не поможет вернуть данные, если с сервером что-то случится. Например, при заражении сервера вирусом копии тоже станут непригодны. Кроме того, регулярно сохраняя копии, можно забить место на диске и не заметить этого, что приведёт к сбою.

Хранение в облаке
Этот вариант более безопасный. Компании всех масштабов осваивают резервное копирование в облако с 2019 года: половина полагается только на облачное хранение, а треть одновременно хранит копии в облаке и на локальном хранилище.

Самыми популярными поставщиками облачных хранилищ являются:

• Amazon S3
• Google Drive
• Dropbox

Минусы и плюсы каждого из вариантов мы рассмотрели в статье «Как настроить бэкапы ISPmanager в Amazon». Автор, наш системный администратор, остановил выбор на Amazon, он исходил из удобства тарифов и репутации компании.

Бэкапы у разных хостинг-провайдеров
Основной сервер с бэкапами у одного провайдера, плюс дополнительные копии — у другого. Хороший вариант: уровень сохранности данных повышается.

У нас есть два варианта резервного копирования: «Диск для бэкапов» — подойдёт тем, кто хочет создавать дополнительные копии и «Автобэкапы».

Диск для бэкапов
Вариант для опытных пользователей, которые занимаются вопросами резервного копирования самостоятельно.

Диск для бэкапов можно использовать:

• Как независимое дисковое пространство. Удобное решение, если вы уже являетесь клиентом FirstVDS. Бэкапы хранятся на независимом сервере, а данные передаются на высокой скорости. Копии можно создавать вручную или использовать панель ISPmanager.
• Как онлайн-хранилище. Подходит для пользователей любого хостинга. К нему можно подключиться по протоколу FTP и использовать для хранения любых файлов.

В обоих случаях резервные копии хранятся в двух экземплярах. По необходимости объём диска может быть увеличен до 1 Тб. Как настроить — в инструкции.

Автобэкапы
Этот вариант экономит время на настройках — не надо искать специальное ПО или писать свой скрипт для бэкапов. Услуга полностью автоматизирует процесс резервного копирования. Как и в услуге «Диск для бэкапов», резервные копии сохраняются на отдельный независимый сервер, только это происходит регулярно и автоматически. Полные копии создаются каждую неделю, а дифференциальные — каждый день. Плюсом ко всему система мониторит состояние резервного копирования — ежедневно проверяет, создалась ли новая копия по расписанию. Предупредит, если что-то пошло не так.

Услуга доступна только для клиентов FirstVDS. Подключить автобэкапы можно как для серверов с панелью ISPmanager, так и без неё. Как это сделать — подробно описано в инструкции.

Привет, привет!

В тревожное время живем, не иначе. И тут главное соблюдать два основных правила, не считая регулярного мытья рук, конечно. Не поддаваться панике — это раз. И не забывать прокачивать скиллы. Это два. Эпидемии когда-нибудь заканчиваются, а полезные знания и навыки остаются с вами на веки вечные. И облегчают жизнь, особенно в кризис.


В мартовском выпуске рассказываем о пяти полезных умениях, которые могут пригодится каждому. А ещё делимся свежими материалами и новостями за месяц. Итак, поехали!

1. Учиться новому
Хороший специалист никогда не перестаёт учиться, потому что знает: мир меняется быстро и нужно успевать меняться вместе с ним. Наш совет — больше читайте и закрепляйте знания на практике, так эффективнее.

Статья в тему
Проверка сайтов после переноса
Вы перенесли данные с сервера на сервер и кажется, что все хорошо. Но на авось полагаться не стоит. Путь профи — пойти и самолично убедиться, что сайты открываются, как надо, а файлы по дороге не потерялись. В нашей инструкции раскрываем пошаговый план, как проверить работу сайтов до того, как вы пустили туда посетителей.
firstvds.ru/technology/check-after-transfer

2. Быть продуктивным
Чтобы успевать больше, не забывайте пользоваться «горячими клавишами», делать перерывы на отдых и выбирать удобные инструменты — сэкономите немало времени.
Статья в тему

Как установить Composer
Пакетный менеджер Composer, если утрировать, работает про принципу Google Play или AppStore — только для языка программирования PHP. Он обеспечивает доступ к библиотекам или расширениям, которые можно найти и использовать для своего PHP-проекта. О том, как установить Composer, рассказываем в инструкции.
firstvds.ru/technology/kak-ustanovit-composer

3. Думать на несколько шагов вперед
Тактическое мышление — то, что отличает профессионала от «чайника». Прогнозируя возможные риски и последствия, хороший специалист ограждает себя от лишних проблем и внедряет превентивные меры ещё до того, как «гром грянет». Чтобы выработать такой навык, начать можно с малого. Хотя бы иногда задавайте вслух вопрос: «Так, а за какую дату у нас есть бэкап базы данных?»

Краткий анонс, и тоже в тему
31 марта весь мир будет праздновать международный День бэкапа. По крайней мере, весь сознательный мир. И поскольку мы не исключение, то уже готовим для вас кое-какие полезности. Не пропустите. И помните, дата праздника выбрана не случайно. Кто знает, к чему могут привести все эти первоапрельские шутки…

firstvds.ru/technology/autobackup

4. Не убегать от проблем, а решать их
Чем дольше откладывается сложная задача, тем страшнее она кажется. Поэтому так важно взглянуть трудностям в лицо и начать действовать. И спокойствия прибавится, и решение найдётся. А теперь — к практике.

Уязвимости месяца
Уязвимость в процессорах AMD, выпущенных после 2011 года
Группа австрийских ученых из Градкого техуниверситета разработала два новых метода атак, перед которыми оказались уязвимы все процессоры AMD, выпущенные в последние 9 лет. С помощью этих атак, под общим названием Take a way, можно получить доступ к конфиденциальным данным через кэш первого уровня. По данным тех же ученых проблему можно блокировать на уровне обновления микрокода. Подробнее на opennet.ru

Уязвимость в pppd и IwIP
В пакете pppd выявлена уязвимость, которая позволяет удалённо выполнить код с правами root. Вызвана переполнением буфера в реализации протокола аутентификации EAP и проявляется как на стороне сервера, так и клиента. Затрагивает версии pppd с 2.4.2 по 2.4.8 и устранена в форме патча. В стеке IwIP тоже имеет место быть, но угрозы не представляет. Чтобы пользователи могли проверить, подвержены ли их системы проблеме, подготовлен прототип эксплоита. Подробнее на opennet.ru

5. Развивать стрессоустойчивость
Одно из главных качеств профи — выполнять свою работу на «отлично» в любых условиях, даже в самых напряжённых. А помочь в этом может тренировка устойчивости к стрессу.

Всего один день, чтобы вырвать максимальную скидку из когтей Фредди! Отвечайте правильно на вопросы и получайте скидки на новые серверы до 25% на 3 месяца. Играйте, пока Фредди не ушёл.

И не забудьте про специальные тарифы. Воспользоваться предложением можно, пока маньяк не забрал их с собой.

Количество серверов для одного аккаунта неограничено.
Акция закончится 18 марта в 23:59 мск.

firstvds.ru/friday13

В этот раз эксклюзивное предложение — новые тарифы Freddy. Компанию им составили VDS Jason — привет от Джейсона Вурхиза с прошлой Пятницы 13. Это серверы со сниженной ценой за увеличенные ресурсы.

Все спецтарифы доступны к заказу только во время акции, до 18 марта 23:59 по МСК. После они исчезнут вместе с Фредди, а купленные серверы останутся с вами по той же цене.



А ещё вы можете победить Крюгера и выиграть скидку до 25% на покупку сервера по другим тарифам. Время действовать, осталось 3 дня.

firstvds.ru/friday13

Игра началась! Фредди задаёт вопросы и отдаёт по 5% скидки за каждый верный ответ. Чтобы получить максимальную скидку 25% на 3 месяца, нужно правильно ответить на все. Если не получилось, попробуйте ещё. Приготовьтесь играть и забирать скидки, пока Фредди снова не скроется во мраке в ночь на 19 марта.

На время акции мы вернули тарифы Jason и добавили два новых — Freddy. Спецтарифы отличаются увеличенными ресурсами по сниженной цене. Они исчезнут вместе с маньяком, а купленные серверы останутся у вас. Цена на них не изменится.

Не проспите! Заходите на страницу акции, победите Фредди и получите максимальную скидку.

firstvds.ru/friday13