Как перенести физически файлы БД mysql с одного сервера на другой?
 

Взломали vds. Я снапшот и скачал. Из него вытащил файлы таблиц и перенес в то же место на локальном компьютере,изменил права. Поставил phphmyadmin.
В админе я вижу эти базы,но лишь частично из всех таблиц 4-5 шт в каждой базе.
Что я не так сделал?:idontnow:

я извиняюсь, а mysql-то сам поставил? :confused:

Plague, конечно :) мне еще резервное копирование cms делать,весь комплект LAMP

Pinky, вообще-то, ЕМНИП, резервное копирование БД (за исключением, разве что, "настольных" Access/Firebird и иже с ними), подразумевает не копирование файлов, а дамп данных.
Не имея представления о структуре пофайлово скопированной БД, сложно сделать сколь-нибудь осмысленное предположение о том, что, как и где у Вас "поломалось"...
Опять же, "снапшот" тоже по-разному можно делать. Если речь идёт о пофайловом копировании данных, изменившихся с последнего бэкапа (дифференциальное резервное копирование) - то для полного восстановления данных нужен не один последний снапшот, а весь комплект, начиная с самого первого, и восстановление тоже должно вестись последовательно: сначала самый старый, потом все остальные в порядке "изготовления".
В общем, информация о способе резервного копирования тоже нужна полная.
Иначе можно долго и бесплодно гадать на кофейной гуще... :vacuum:

Если все таблицы - MyISAM, то копирования директории базы достаточно (проверено неоднократно). А вот если появляется "Инна" (InnoDB) - то там эта метода уже не пляшет, они лежат вообще не в директории, а в файлах %mysqldata%\ibdataXX причем одной кучей от всех баз. Так что таскать в этом случае нужно вообще всю директорию хранилища mysql, и то не факт что проканает; я не помню - делал я такое или нет.

Не, оно и для M$ SQL работает, и для Oracle, и для много ещё для чего. Практически для всех БД, хранящих данные в одном файле (или, как минимум, в одной отдельной папке). Просто неплохо бы, в большинстве случаев, к этому добавлять ещё и бэкап самой СУБД (зависит от разработчиков, но зачастую кое-какие существенные настройки БД хранятся в системных таблицах самой СУБД).
А ведь вышеупомянутые СУБД позволяют ещё и "размазывать" БД по нескольким устройствам (логическим или физическим); есть ли такая фича у MySQL - просто не знаю...
А так - да, остановил сервис СУБД и копируй на здоровье. В M$ SQL я так даже как-то переносил "однопапочную" базу (detach на одном сервере перенос, attach на другом)...

По-научному оно всегда правильней, просто иногда нет такой возможности. Топ-страртер пишет что VDS ломанули - хз до какой степени, может там кроме файловой нифига и не доступно, и то с родительского уровня.

Так может и файлы не все доступны. Я почему-то думал, что под "снапшотом" подразумевается некая разновидность бэкапа...
В общем: дело ясное, что дело тёмное...

Vds взломали и начали рассылать спам. Vds заморозили. Как только делается разморозка через 2 минуты снова замораживают. Снапшот - пофайловый архив всей системы около 2гб(первый и единственный) сделан после обнаружения проблемы. Возможности запустить на сервере что-то типа phpmyadmin или дампера нет возможности. Виртуальная машина остановлена. В каталогах баз на первый взгляд все таблицы. До изменения прав доступа к таблицам (/var/lib/MySQL/имябазы с root на MySQL я видел все таблицы базы. После смены прав на MySQL вижу только пару таблиц из базы.

Так значит проблема именно в том, что неправильно поменяны права доступа к файлам?..
При таком раскладе сложно что-то присоветовать не имея понятия о том, какие права были изначально (на работающей БД) и какие выставлены теперь...

Может есть возможность физические файлы перевести в дамп? Или чем открыть их? Нужно то пару таблиц только.

Под рутом они нормально открывались? Верните взад права и делайте дамп сколько угодно.
Проще, конечно, это делать в консоли. Утилитой mysqldump или непосредственно консольным клиентом (что в линуксе не знаю, а в винде mysql.exe и mysqluc.exe).
Вот только чем может помочь сейчас изготовление дампа, если и так известно, что все данные на месте, а проблема именно в правах доступа?..

вообще странно. в смысле что проблема частичная. тоесть если права не те, то должно отвалиться всё.
если эксперименты проводятся на локальной машине, то chmod -R ugo+rX на всё это, может поможет :) (только не на рабочей площадке!!)
у меня на фряхе базы лежат с правами mysql:wheel 700 для директорий и 660 для файлов.

как меня учил дружище Хэлл:
дампит и на лету топчет в бзип

Под рутом не открывались ошибку давали,что не обнаружена таблица или нет доступа. Попробую выставить права 777 может получу доступ,машинка локальная,тестовая.

:contract:
добавить права чтения (+r) всем (user, group, other) а так же права на выполнение (т.е. вход) в каталог (X) для них же.

Поменял права для базы maksimovskiy и вот что получаю.
Скрин из phpmyadmin и список файлов в базе.

На скрине написано: "Таблица khalw_categories не существует".
В списке файлов есть файл описания таблицы "khalw_categories.frm", но отсутствуют файлы с данными "khalw_categories.MYD" и индексами "khalw_categories.MYI".

Каждая таблица хранится соответствующем комплекте файлов (frm+MYD+MYI). Это MYISAM engine.

У Вас от всех таблиц (кроме "khalw_cache_content") в списке только описатели...

Делаем вывод: в наличии схема БД, самой БД нет...

P.S. Если вдруг я неправ и остальные таблицы хранились не в MYISAM, а в InnoDB, то данные должны лежать в файлах Таковых в списке тоже не наблюдается...
Читать здесь.

Данные файлы ест в снапшоте,я их копировал /var/lib/mysql логфайлы по 5мб, ibdata1 ~200мб.
Содержимое /var/lib/mysql

А права на эти файлы (и каталог) у учётки, от имени которой работает mysqld, есть? А mysqld знает о том, что файлы данных нужно искать именно по этому пути? А в самом MySQL права у учётки, от имени которой коннектится PHPMyAdmin, на доступ к БД есть?
Проверяйте конфигурацию мускуля, проверяйте права на папки. Если данные есть - их можно вытащить (навряд ли они зашифрованы).

P.S. Посмотрел, инна может хранить таблицы и в отдельных файлах (ibd) рядом с frm (у меня виндовый мускуль именно так и делает).
В общем - первым делом нужно выяснить, в каком виде хранились данные в изначальной БД. Гадать на кофейной гуще - надоело...