Случайно удалите /usr/share/* каково правильное решение для резервного копирования данных?
Как?
При попытке создать изолированную среду для некоторых пользователей я использую
mount --rebind <path> <newPath>
Для того, чтобы позволить пользователям в режиме chroot получить доступ к некоторой полезной команде (да, это плохая практика)
После некоторых обсуждений с коллегой я передумал и решил использовать группы, чтобы занести в черный список какую-то папку для пользователей, находящихся в chroot. После некоторых
umount <path>
Я заканчиваю тем, что делаю немного rm -rf. убрать последнюю папку
Худшая идея, которая у меня когда-либо была
К сожалению, я забыл размонтировать папку / usr / share и rm начал удалять файл в этом каталоге. Надеюсь, я сделал быстрый
Ctrl + C
После того, как я заметил свои ошибки. Я был как "Круто, не слишком много повреждений"
Я был действительно неправ.
Все мои сервисы (mysql; postregsql; java) больше не могут работать, потому что им нужны зависимости в / etc / alternatives.
update-alternatives --force --all
Помогите мне немного, но не помогает запуск MySQL. Я полностью потерял веру в исправление этого, поэтому я хотел бы сделать резервную копию каждого файла конфигурации и выполнить чистую установку моего VPS. Но, как вы думаете
У меня нет резервной копии базы данных
Я знаю, что это действительно очень неправильно, пожалуйста, прости меня.
Мой вопрос
Теперь давайте перейдем к моему вопросу, есть ли способ восстановить соединение PostreSQL и MySQL, чтобы сделать резервную копию базы данных и сохранить ее для выполнения чистой установки на моем VPS? Или я совсем потерян?
Пока что я пробовал:
- воссоздать сокет базы данных (на самом деле не работает)
- Регенерируйте файлы данных MySQL и переместите мои файлы блоков в папку (Это помогает запустить MySQL, я могу просмотреть базу данных и таблицу, используя SHOW DATABASES; и SHOW TABLES; но я не могу получить к ним доступ)
Заметки
В футуре сделаю бекап, обещаю
Обновить:
Согласно PostreSQL: https://www.postgresql.org/docs/9.1/static/backup-file.html существует способ резервного копирования базы данных с использованием fs. Я попробую это
Спасибо, что нашли время, чтобы прочитать меня, надеюсь, у вас будет и идея.
3 ответа
Для тех, кто интересуется, есть ли решение, я наконец нашел его!
Сначала я скачал gdrive клиент терминала Google Drive.
Затем я сделал несколько резервных копий всех важных каталогов (/home, /etc/nginx, ...). И для моего сервера MySQL и PostgreSQL я создал резервную копию следующего каталога:
- / var / lib / mysql <- для MySQL
- /var/lib/postgresql/9.3/main <- для PostgreSQL
Я загрузил резервную копию тезисов на диск Google и переустановил VPS
Наконец, я переустановил сервер MySQL, остановил демон, сделал резервную копию оригинального / var / lib / mysql и скачал с Google Drive мой старый. И после небольшого исправления разрешения сервер запустился! И вуаля моя база данных вернулась и функционала!
Я не проверял реимпорт данных PostgreSQL, но думаю, что это сработает, попробую завтра.
В любом случае, это будет хорошим уроком для меня: несмотря ни на что, всегда делайте резервные копии!
Обновить
Просто закончите импортировать мой дамп PostgreSQL, ничего не потеряно!
Помимо настройки ежедневного / почасового резервного копирования, всегда рекомендуется создавать резервные копии, в частности, папок, над которыми вы собираетесь работать, непосредственно перед тем, как прикоснуться к вашей системе, и это правило становится еще более важным, если это производственная среда.
В вашем случае я бы посмотрел на mysqldump и эквивалент postgres.
Как правило, вы восстанавливаете данные из резервной копии или, если потерянные данные были критически важны, найдите новую работу.
Как правило, я бы предложил использовать службу восстановления данных, но это требует немедленного выключения устройства после аварии. Это также очень дорого и требует много времени.