Как крупные компании делают резервные копии своих данных?

Это зависит от вашей цели.

Если вы ищете резервные копии для аварийного восстановления (сервер взорвался, центр обработки данных сгорел и т. Д.), То краткий ответ - они могут вообще не делать резервные копии. У нас есть клиент, который имеет дело с конфиденциальными правительственными данными, и часть его мандата заключается в том, что мы не разрешено делать резервные копии или резервные копии на съемных носителях. Нам разрешена репликация в реальном времени на сайт аварийного восстановления и все. Оба сайта имеют одинаковый уровень физической и логической безопасности. Загвоздка здесь в том, что если я что-то напортачу на сайте A, то это практически мгновенно реплицируется на сайт B.

Если вы говорите о резервных копиях с точки зрения целостности данных (например, вы случайно уронили таблицу «Клиенты», и она уже реплицирована на сайт аварийного восстановления), то ленты LTO-5 в большой ленточной библиотеке часто подходят. Имея до 3 ТБ на ленту и несколько лент в ленточной библиотеке, вы можете быстро выполнить резервное копирование огромных объемов данных (быстро здесь подразумевается Мбит / с, для резервного копирования 25 ТБ данных может потребоваться много-много часов).

Любой достойный пакет резервного копирования будет выполнять сильное сжатие и устранение дублирования, что значительно сокращает объем необходимого дискового пространства. Однажды я видел оценку для сжатого и де-дублированного инструмента резервного копирования Exchange, в котором заявлено соотношение 15: 1 (15 ГБ данных хранятся в 1 ГБ резервных копий).

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

Собственно, похоже Google делает резервную копию огромного количества данных на ленту, что не совсем то, что я ожидал:

Большая часть их данных хранится в их собственной файловой системе GFS, и GFS требует наличия как минимум трех копий каждого блока размером 64 МБ, из которого создается файл (GFS использует блоки размером 64 МБ). При этом я не думаю, что они беспокоятся о резервных копиях, поскольку у них есть как минимум три копии каждого файла, а блоки на отказавшем узле можно быстро заменить, просто реплицируя данные из любой из оставшихся двух хороших копий на новый узел.

Для получения дополнительной информации взгляните на http://labs.google.com/papers/gfs.html

Ответ дальновидного хорош, но я думаю, что его можно прояснить, если подумать об этом с такой точки зрения: что вы пытаетесь восстановить? Это для ДР? Какое время требуется для восстановления? В качестве примера предположим, что ваша компания использует базу данных sql-сервера объемом 25 ТБ. В случае сбоя или ошибки данных (отброшенная таблица, поврежденная база данных и т. Д.) Технический директор хочет иметь возможность восстановить базу данных менее чем за час. В случае сбоя сайта потребуется 2 часа.

На первый взгляд это звучит сложно, но возможно. Поскольку вы знаете, что ваша стратегия резервного копирования должна восстановиться через час, вы знаете, что вы не собираетесь восстанавливать полные резервные копии, вам придется работать с командами dba, чтобы гарантировать, что БД разбита на управляемые фрагменты. Вы также собираетесь делать частые резервные копии журналов. Для аварийного восстановления следует обратить внимание на стратегию репликации (возможно, версию с задержкой по времени с репликацией данных журнала в реальном времени, но не применяемой). Как сказал дальновидный, это зависит от цели, и эта цель должна заключаться в некоторой форме выздоровления.