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

Особенно понравилось про именно ТРИ последних бэкапа. Я до сих пор по одному только хранила. Теперь последую твоему совету. Спасибо!

Яков, ну, со спидом, конечно, перебор. Но в целом суть ясна
larmaks, можно больше А вот меньше - не стоит.

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

Бррр!... Бэкапы на почту, какие-то сохранения... У меня на сервере реализован свой механизм бэкапирования в место, куда веб-серверу тупо запрещен доступ. Хранятся бэкапы за 4 дня. И всем хорошо: и мне и моим юзерам. А у хостеров, по крайней мере shared-хостинг точно, бекапирование идет вообще на отдельные тачки, сроки такие же - от 4х дней до 2х недель. Достается элементарным обращением к хостеру.

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

Куда же у тебя бэкапы идут? А каким-таким механизмом, если не секрет? 

Где разница - за бугор или нет? Совершенно без разницы, к бэкапным тачкам нет доступа по пользовательским протоколам. Я могу судить по топовым хостерам у нас - ХЦ РБК, Агава. Мастерхост вроде тоже умеет, но тамошние ребята просто обожают все делать через жопу. Бэкапы пока что складываются в отдельный каталог /bkp в корне сервера (я, наверное, забыл упомянуть, что держу свой VPS). Пока объем бэкапов всех юзеров не велик - около 300Мб. Потом, если превысит гиг - будут ложиться на внешний жесткий диск, благо мой хостер это позволяет реализовать. Механизм - банальный bash-скрипт в кроне. Касательно технологии. Существует одно неписанное (точнее оно писанно, в конфигах as default) правило хостинга: веб-сервер никогда и ни за что не имеет доступа к данным, расположенным выше public_html (она же www). Большинство хостеров данное правило чтут, хотя отморозки тоже встречаются. Если доступа таки нет - единственный способ угрохать данные выше данных директорий - грохнуть их по ftp/ssh. То есть если не угнан пароль от хостинга - бояться не стоит. Если же есть мнение, что пароль могут угнать, то стоит вспомнить, что пока что (слава йайтцам!) скрипты, заражающие локальную машину, не обучены всем премудростям шелла. Из основных премудростей, которые в различных контекстах использую я для бэкапирования и хранения набора скриптов, запускаемых в хомяках клиентов: 1. нулевые права или чмод (man chmod для посмотреть) - при правах на папке/файле 0000 никто и ничто (кроме рута, конечно) не сможет даже просмотреть файл/войти в папку 2. флаги - unix-системы хороши тем, что позволяют устанавливать на файлы/папки различные флаги. В данном контексте самые полезные два - запрет изменения файла/папки и запрет удаления файла/папки. Поскольку все скрипты, которые я запускаю у клиентов, находятся в открытом доступе, все они подобным образом приведены к состоянию "могу читать и больше ничего". Ничего то есть вообще. Единственный вариант их изменения даже мной - снятие флагов и восстановление прав. А боты не умеют диагностировать и "исправлять" данные вещи по одной простой причине - на сегодняшний день вероятность того, что при успешной попытке кражи паролей бот столкнется с подобным - ноль (да-да, именно так). Так что разработчики ботов и троянов просто-напросто не реализуют данные механизмы.

Во понаписал-то)

С нулевым chmod'ом интересный способ сохранить данные 

Дык. Сегодня единственный способ сохранить данные где-либо - запретить к ним доступ.
Вообще тема защиты - довольно бесконечная тема.
Например, когда все мы были еще на старом сервере однажды нас задолбала ситуация, когда кучи ботов подбирали пароль рута к нему. Пробовалось множество различных решений.
Сейчас все выросли, и на моем сервере руту просто-напросто полностью запрещена авторизация по ssh/ftp. Доступ к нему могу получить только я.
А доступ по SSH в целом можно получить только с ограниченного списка IP-адресов и подсетей. Данная задумка особенно кошерна, и на shared-хостинге она просто не реализуема.

Однако нужно четко понимать, что какую бы защиту не устанавливали на сервер, где хостится тот же WP и какими бы средствами она не была реализована, заражение локальной машины может стать угрозой всему.
Любой хостер, любые ухищрения с защитами и бэкапированием могут максимум свести к нулю время восстановления данных. К примеру, на то, чтобы восстановить полностью контент и базы пользователя моего сервера - нужно потратить чуть больше 3х минут, если есть навык работы с SSH и чуть менее 20ти если его нет; а на восстановление данных у хостера, предоставляющего бэкапирование на удаленную машину может уйти от 4х часов у хорошего хостера и до суток у плохого. Связано это в первую очередь с несовершенством сегодняшних агоритмов бэкапирования, да и систем в этом плане, и бОльшая часть времени будет потрачена на получение архива нужного юзера за нужную дату с бэкапной тачки.