Научите, пожалуйста:

1. На что и почему следует обращать внимание при выборе места под удаленное хранение резервных копий сайта?

2. По какой схеме и с помощью какого софта (под *nix) лучше организовать автоматическое создание резервных копий?

0. На репутацию предоставляющего услугу, согласие отвечать более чем абон платой за гибель данных. При, не дай боже, боязне adm ресурса - на географию расположения ..
1. При больших объемах на скорость доступа.
2. Нужно понимать что бекапим - в некоторых случаях обычный dump ну или amanda над ним являеться лучшим решением, в некоторых его комбинация с mysqldump,. есть fsbackup к которому можно прикрутить на дальшей машине slave mysql.....

Первое чему я научился - упомянутый mysqlDump и SCP.

Добавить к этому архивацию (zip-tar - что угодно).
Имеем три компоненты архиватор для фалов, mysqldump для таблиц, и scp для передачи.
Добавить crontab, и подождать до готовности.
Подавить с желательно не очень удаленным сервером и широкими каналами.

Но это я все к чему.
Договориться о выделении места под бекапы можно всегда и со многими физическими и юридическими лицами. Желательно чтобы этот весь ракетный комплекс работал в пределах одного ДЦ/региона.
Согласитесь, не логично посылать бекапы из России с США при биллинге трафика по соотношениям, да еще через океан, далеко и с высоток не видно.

PS научить можно разными способами. По-моему мнению, правильно заданный вектор - 90% самостоятельнго решения.

Все зависит от задачи. Если задача - просто хранение данных, то таки lazutov прав.

Если задача - макимально быстрое развертывание бэкапа "если что" - то создание полных образов (или как их назвать? срезов?) HDD\нужных разделов. Места они занимают ой не хило, но зато восстановление из бэкапа - 3 клика мышью + полчаса времени (ну, если канал не мешает и винтики не IDE).

Снапшоты (snapshot), наверное, - мгновенные копии файлов, директорий и всей операционной системы на определенный момент в времени. Так?

под это дело есть замечательный надежный вариант решения "через дальнее кукуево".

Берем сервер. Отрезаем от него процентов 80-90 и заворачиваем в виртуализацию. Причем ограничения на ресурсы ставим не анлим, а 80-90% от мощности сервера.

Имеем: заизолированную(пусть и виртуальную) машину, с которой можно ксерить копии очень причем средствами ядра виртуализации[могу ошибаться, не уверен] часто и выкатывать архивы не сложно. при ддосе(не дай бог):
Если не забьют канал, управляемо из-под базового сервера. Можно снять копию и выкатить в другое место.
Если забьют - через второй линк(если есть). =)

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

Ответ на второй вопрос это дамп базы (чем не важно) и дальше бекап нужных данных либо всего сервера обычным rsync

Ответ на третий вопрос (которого нет) - могу помочь

Ответ на этот вопрос я знал , спасибо.

А что значит "как он хранит данные"? Как их можно хранить и как хранить правильно?

Для действительно важных сайтов данные надо бэкапировать не на сервер, а в файловый массив датацентра.
Ни в коем случае не того же, где расположен сам сервер сайта.
Желательно в другой стране (хорошо бы на ином полушарии и с непохожей политической системой (если есть за что..) .
Так как большинство датацентров доступа к хранилищу извне не предоставляют, минималистический сервер либо VDS как промежуточное звено - обязателен. А уже с него - бэкап в файлохранилище.
Дорого? Да.
Сложно? Да.
Напрочь потерянная информация лидера рынка стоит в разы дороже...

Рискую во многом повториться, но все же


Все зависит, от чего хотите обезопасить проект.
1)От смерти железа - идеально чтобы бэкапный сервер был в том же ДЦ, что и Ваш проект. Это дает огромную скорость и [почти всегда] неограниченный трафик. Соответственно, большая скорость означает и быстрое восстановление данных, если припрет.
2)От аварии в ДЦ - идеально если другой ДЦ того же провайдера, или ДЦ любого провайдера, имеющего в широком смысле слова пиринговые отношения в Вашим ДЦ.
3)От аварии на магистральном оборудовании провайдера, аплинках провайдера, от серьезных атак на кого-то расположенного пососедству - тут зависит от требований к объему и скорости бэкапов и готовности платить за трафик. В идеале - другой конец света (если проект в России, то Штаты, или Европа хотябы). Тут Вы оперативно получите доступ к бэкапу даже если у хостера умерло ядро сети, или основному аплинку рубанули ковшом экскаватора оптику.

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



Опять же. Что бэкапим, какую цель преследуем? Вариантов массу уже называли. Для периодических бэкапов мне нравится fsbackup - настраивается крайне гибко, умеет делать инкрементальные бэкапы, складывает их в локальные папки, по ftp или ssh.

На счет 1-го варианта все написано уже верно
На счет 2-го варианта - предложу Failover для бедных. На примере cPanel, но прикрутка может быть к любой другой панельке, которая имеет функции backup/restore

Вот, спасибо.

Речь идет о ХО, естественно. Т.е. о проекте, который нужно резервировать только "на всякий случай", исключая политические гонения .

Как я понял, оптимальный вариан - ежедневный снапшот на какое-нибудь не супер-пупер железо, расположенное где-то поблизости с рабочим сервером (для быстрого восстановления в случае проблем с железом), плюс ежедневный инкрементный бекап в другой ДЦ, желательно, связанный одной веревкой с моим (для вдумчивого восстановления на случай погибели ДЦ[маловероятно] или на случай порчи отдельных данных в бд, например[весьма вероятно]).

Инкрементный - для экономии трафика и чтобы можно было "откатиться" на какую-то дату при необходимости. Т.е. сначала делаем полный "слепок" всей системы, а потом дописываем (не переписываем, а именно дописываем) только измененные/новые файлы.
Так?

И еще третий вариант - rsync
Который является оптимальным

А что за зверь и почему оптимальный?

rsync — (англ. Remote Synchronization) это программа для UNIX-подобных систем, которая выполняет синхронизацию файлов и каталогов в двух местах с минимизированием трафика, используя кодировку данных при необходимости. Важным отличием rsync от многих других программ/протоколов является то, что зеркалирование осуществляется одним потоком в каждом направлении (а не по одному или несколько потоков на каждый файл). rsync может копировать или отображать содержимое каталога и копировать файлы, опционально используя сжатие и рекурсию.

источник

Форум - это не движок, и даже не место общения. Форум - это люди.
У нас форум отличный. Спасибо за ответы и разъяснения.

Насколько я понимаю структуру ХО - есть сайт и форум.
Оба на файлах(которые редко меняются)+БД(на СУБД)
То есть: один раз слить файлы и делать это при изменениях
при этом регулярно копировать только БД.

Или я чего-то глобально не понимаю?

Все правильно понимаете, пхп-скритты и пара БД. Плюс почта и прочая шелупень, включая ОС , это тоже ХО, и там тоже иногда что-то меняется.

значит остается rsync и метод ,описанный мной выше, через виртуализацию.

А это значит данные можно хранить на:
1) на одном SATA диске
2) на одном зеркале из двух SATA дисков
3) на ещё каком либо рейде типа 10 например
4) на 5 рейде
5) на стримере
и дальше разновидности

если на одном то есть риск что бекап умрет вместе с этим одним диском
если зеркало то бекап может быть в двое дороже.


Да и я про rsync писал - уже выше написали что это такое - но по большому счету не важно что это такое если бекап доверите делать кому-либо, то настроют и будет работать, главное чтобы доступ к бекапу дали