Подскажите хотя бы, в принципе это должно так работать, кто-нибудь когда-нибудь делал также, создавалась ли у него база данных через ispmanager -> Планировщик CRON, может так и нельзя делать?
В консоли эта же команда без пробела между аргументом –uи логином пользователя от базы данных и даже без дополнительного параметра --no-tablespaces, даже с ошибкой:
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces
И то все равно база данных создается. С параметром --no-tablespaces создается вообще без ошибок, только с предупреждением что пароль не стоит светить в консоли:
mysqldump: [Warning] Using a password on the command line interface can be insecure.
И тоже база создается без проблем.
Хм… не понимаю, что этому isp’шному cron’у нужно, он разве не тоже самое делает выполняет ту же команду также, по заданному времени?
1. Проверь права на файл. Вдруг они 400, например. 2. Точно пользователь мускуля, а не линуха?
Права созданного пустого файла с 0 Кб 664 - -rw-rw-r—.
Пользователь за аргументом –uэто пользователь и владелец базы данных со всеми правами, это точно не пользователь системы.
Эта команда безошибочно работает и создает дамп базы в консоли, но что ей не нравится в ispmanager’е CRON непонятно, более того новое задание которое архивирует и создает архив файлов упаковывая сайт в zipработает без проблем, то есть файл бэкапа в zipформате создается и он не пустой, даже если не считать мне непонятное приписование то ли ispmanager’а то ли CRON’а в конце моей команы >/dev/null 2>&1, все равно архив с файлами создается, а вот архив с базой данных нет, ну то есть как нет, тоже создается но пустой и весит 0 Кб.
Зачем что-то жать в кроне? Пишешь скрипт, задаёшь задание в кроне на его выполнение, и всё будет работать. И попробуй не -uuser, а -u user.
Так пробовал, тоже самое, а вот скрипт не пробовал, надо будет попробовать, хотя странно что без скрипта простая команда не сработала, ну то есть как, файл то она создает, но он пустой.
Вы пароль оставляете в истории команд. Если история кому попадет в руки, то вашу базу уведут. Но увести её могут лишь при неверных правах доступа, что само по себе опасно.
То есть очень ли опасно? Нет. Но из таких не столь значительных моментов и состоит безопасность. Учитесь работать правильно, тогда и вероятность взлома можно свести к минимуму. Это ведь просто дело привычки, особых неудобств в этом нету.
Да это понятно, я уже ввел случайно, да действительно historyотображает введенный пароль, я так понял history–cкоторая очищает историю решает это случайное введение пароля ну хотя бы на уровне истории введенных команд.
Да похоже на это, там кстати этот чувак у которого проблема пишет что типа это проблема в браузере типа в хроме у него все ок:
prcdpr:
On Chrome it's fully compressed! So it's a Firefox problem.
Я где-то тоже мимо ходом читал что это возможно баг в браузере, но хз на сколько это так или не так. Если так то и фиг с ним.
На сервере все zip’ы, gzip’ы точно работают, да и в web-приложениях, WordPress же обновления в тоже толи в zip’ах толи в gzip’ах получает и распаковывает, да и сам phpMyAdminэкспорт с сжатием в обычный zipнормально базу создает и скачивает.
Ладно, наверное это не так страшно, и никак не чинится, фиг с ним, не буду с этим заморачиваться пока. В обычных зипах похраню базу, не рассыплюсь. Хотя конечно странная фигня.
Нет никакого "isp'шного" cron' а, ispmanager просто добавляет задачу в системные файлы cron.
Какая у вас в итоге команда в задаче?
Все та же:
mysqldump --no-tablespaces -u user_name -pPASSWORD data_base > database.sqlМожет ему поддчеркивания в имени пользователя и в названии базы данных не нравиться - _?
crontab -e делал
В консоли эта же команда без пробела между аргументом –u и логином пользователя от базы данных и даже без дополнительного параметра --no-tablespaces, даже с ошибкой:
И то все равно база данных создается. С параметром --no-tablespaces создается вообще без ошибок, только с предупреждением что пароль не стоит светить в консоли:
И тоже база создается без проблем.
Хм… не понимаю, что этому isp’шному cron’у нужно, он разве не тоже самое делает выполняет ту же команду также, по заданному времени?зачем это вообще надо, если там есть система бэкапов?!
1. Проверь права на файл. Вдруг они 400, например.
2. Точно пользователь мускуля, а не линуха?
Права созданного пустого файла с 0 Кб 664 - -rw-rw-r—.
Пользователь за аргументом –u это пользователь и владелец базы данных со всеми правами, это точно не пользователь системы.
Эта команда безошибочно работает и создает дамп базы в консоли, но что ей не нравится в ispmanager’е CRON непонятно, более того новое задание которое архивирует и создает архив файлов упаковывая сайт в zip работает без проблем, то есть файл бэкапа в zip формате создается и он не пустой, даже если не считать мне непонятное приписование то ли ispmanager’а то ли CRON’а в конце моей команы >/dev/null 2>&1, все равно архив с файлами создается, а вот архив с базой данных нет, ну то есть как нет, тоже создается но пустой и весит 0 Кб.Зачем что-то жать в кроне? Пишешь скрипт, задаёшь задание в кроне на его выполнение, и всё будет работать.
И попробуй не -uuser, а -u user.
Вы пароль оставляете в истории команд. Если история кому попадет в руки, то вашу базу уведут. Но увести её могут лишь при неверных правах доступа, что само по себе опасно.
То есть очень ли опасно? Нет. Но из таких не столь значительных моментов и состоит безопасность. Учитесь работать правильно, тогда и вероятность взлома можно свести к минимуму. Это ведь просто дело привычки, особых неудобств в этом нету.
Что-то похожее: Exported gzip file of database has first ~73 kB uncompressed and rest is gzip compressed · Issue #16042 · phpmyadmin/phpmyadmin (github.com)
Да похоже на это, там кстати этот чувак у которого проблема пишет что типа это проблема в браузере типа в хроме у него все ок:
prcdpr:
Я где-то тоже мимо ходом читал что это возможно баг в браузере, но хз на сколько это так или не так. Если так то и фиг с ним.
На сервере все zip’ы, gzip’ы точно работают, да и в web-приложениях, WordPress же обновления в тоже толи в zip’ах толи в gzip’ах получает и распаковывает, да и сам phpMyAdmin экспорт с сжатием в обычный zip нормально базу создает и скачивает.
Ладно, наверное это не так страшно, и никак не чинится, фиг с ним, не буду с этим заморачиваться пока. В обычных зипах похраню базу, не рассыплюсь. Хотя конечно странная фигня.