IT

Раньше, в одной из заметок, я описывал настройку локального бэкапа файлов на сервере с помощью rsync. Но локальный бэкап хорошо, но хотелось и удаленный. Можно, конечно, при наличии нескольких доступных серверов организовать через тот же rsync, но хотелось сделать это в облако, более того в облако надежное (я таковым считаю Google Drive). Плюсы Google Drive:

1. 15Гб места на аккаунт бесплатно.
2. Аккаунтов можно завести любое необходимое множество.
3. При необходимости место расширяется до 100Гб всего за $1.99 в месяц или же 1Тб за $9.99 в месяц и т.д..
4. Исключительная надежность.
5. Быстрый и простой доступ из любого места (как с помощью специального ПО, так и через браузер).

Недавно у меня на хостинге появился сайтик на WordPress, уж не знаю чем он так полюбился кому, но стал замечать, что регулярно идет к нему POST запрос на wp-admin.php с разных адресов  - видимо пароли подбирают или еще что-то. Это создавало ненужную нагрузку на сервер (в моем случае не критичную, но все же).

Озадачился решением проблемы. Гугление дало вариант, который мне понравился.

Вообще-то rsync конечно же дает прекрасные инструменты для удаленного архивирования по сети. Но... Для начала неплохо иметь копии локально, за N дней. На случай сбоя, какой-то правки неправильной и т.п.

Мне хотелось иметь архивы сайтов, т.к. иногда находит "порукоблудить" и не всегда сразу заметишь, что чего-то напортачил. И когда через день-два это все всплывает - начинаешь мучительно вспоминать какие строки и где менял. Сначала я просто архивировал (опять же через periodic daily) папки с сайтами и хранил N, а иногда и M (шутка) дней. Но архивирование очень сильно поглощает процессор - задача непростая. К тому же большинство сайтов основной свой объем имеют за счет картинок, архивов и т.п. (тексты в основном в БД, остаются скрипты, но их не так много по объему) - т.е. вещей в принципе не жмущихся архиватором. Следовательно проще просто копировать файлы. Но зачем копировать все, если за день меняется от силы 10% содержимого сайта?

В сети масса статей, подробно расписывающих почему для отдачи статики с сервера нужно использовать nginx, а не apache. Это и быстрее и менее нагружает сервер и т.д. Поэтому я на этом сейчас останавливаться не буду.

Проблема с CMS Drupal (именно с ней я больше всего работаю - она очень удобна и практична) состоит в том, что файлы стилей (css), javascript (js), а в при применении некоторых модулей (например colorbox, ubercart) и изображения (разных стилей - превью и т.д.) генерируются динамически. Т.е. система физически записывает файл на диск (формирует объединенный css или js, обрабатывает исходное изображение) только после первого к нему обращения. При чем после сброса кэша файлы css и js меняют свое имя и создается заново. Именно поэтому самый распространенный в сети пример конфига nginx для отдачи статики не подходит.

Здесь я опишу альтернативный вариант конфига для nginx+apache+drupal, позволяющий отдавать картинки, css и js через nginx и при этом не боятся получить ошибку 404 Not Found при сбросе кэша и/или первичном формировании картинки.