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

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

Начиная с версии 4.0, сервер MySQL поддерживает преобразование кодировок символов. Эта статья рассказывает о том, что такое кодировки, сопоставления и о том, как работать с ними применительно к серверу MySQL.

Введение

Начиная с середины 90х, ext/mysql служило основным мостом между PHP и MySQL. Хотя в нем имелись недостатки и проблемы росли с годами, в общем, ext/mysql делал свое дело неплохо и шел в ногу с изменениями как в PHP, так и в MySQL.

Однако с появлением PHP 5 и MySQL 4.1 все изменилось - начали образовываться несколько достаточно обширных трещин.

В ext/mysql имелись "достоинства, оказавшиеся недостатками": в первую очередь это mysql_pconnect(), подключение по умолчанию и автоматическое подключение. Кроме того, проявились несовместимости между функциями ext/mysql и теми, что поддерживались клиентской библиотекой MySQL, на которой основаны и ext/mysql, и ext/mysqli.

В попытке исправить эти расхождения, Георг Рихтер создал очередное расширение PHP 5, которое поддерживает новые возможности MySQL 4.1+. Это расширение получило название ext/mysqli, где 'i' заменяет одно из слов: improved(улучшенное), interface(интерфейс), ingenious(изобретательное), incompatible(несовместимое) or incomplete(неполное).

Служба каталогов Microsoft Active Directory стала одним из важнейших компонентов многих IT-сред. Одной из важнейших возможностей службы Active Directory является поддержка групповых политик, позволяющих администраторам централизовать управление контроллерами, серверами и рабочими станциями домена.

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

Возможности делегирования, предусмотренные в службе каталогов Active Directory, весьма значительны; они решают ряд проблем защиты и упрощают задачи управления. Грамотное делегирование прав в службе Active

Directory® позволяет регламентировать применение в среде определенных ролей, уменьшить вероятность и нейтрализовать последствия административных ошибок, реализовать в существующей инфраструктуре принцип наименьших привилегий. В то же время, многие организации, опирающиеся в своей работе на службы Active Directory, до сих пор не воспользовались потенциалом функции делегирования. Отчасти это объясняется кажущейся сложностью разработки модели делегирования в корпоративной среде службы Active Directory. Действительно, сформировать модель делегирования, отвечающую индивидуальным потребностям предприятия, сложнее всего, но с другой стороны, существует множество простых моделей, которые можно реализовать в большинстве ИТ-сред лишь с незначительными изменениями.

Active Directory — одна из самых критичных служб в сети Windows. Чтобы свести к минимуму время простоя и снижение производительности, очень важно иметь эффективные планы аварийного восстановления при неполадках в Active Directory. Это может показаться очевидным, но

просто поразительно, сколько администраторов не имеют плана восстановления при возникновении одной из наиболее вероятных проблем с Active Directory®: случайного удаления данных.

Случайное удаление объектов — одна из наиболее распространенных причин сбоя службы. Когда я провожу семинары или конференции, я часто спрашиваю, сталкивался ли кто-нибудь с неполадками в Active Directory из-за случайного удаления данных. И каждый раз почти все поднимают руку.

Чтобы понять, почему так сложно проходит восстановление данных, сначала следует понять следующее: как Active Directory хранит и реплицирует объекты, и в чем заключается механизм полномочного и неполномочного восстановления.

Существует множество установок безопасности, которые могут быть сконфигурированы в одном Объекте Групповой Политики (Group Policy Object). Эти установки ранжируются от контроля аккаунта Администратора для контроля LDAP подписания требований клиента. При таком большом количестве защитных установок очень важно понимать функционирование и режим работы, который не так очевиден, как можно было бы себе представить. В декабре 2004 года я написал статью про “Осуществление групповой политики защитных установок ”, которая даст вам некоторый детальный взгляд изнутри на то, как защитные установки могут применяться в обычной среде. В этой статье я раскрою суть концепции (включая некоторые регистровые “хаки”), а также некоторые наиболее общие сценарии, в которых установки безопасности ведут себя не так как положено.