Назад | Перейти на главную страницу

Случайно удалите / usr / share / * какое решение для резервного копирования данных правильное?

Как ?

Когда я пытаюсь создать chrooted-среду для некоторых пользователей, я использую

mount --rebind <path> <newPath>

Чтобы позволить chrooted-пользователям получить доступ к какой-то полезной команде (плохая практика, да)

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

umount <path>

В конце концов я делаю немного rm -rf. очистить последнюю папку

Худшая идея, которую я когда-либо имел

К сожалению, я забыл размонтировать папку / usr / share и rm начать удалять файл в этом каталоге. Надеюсь, я быстро

Ctrl + C

После того, как заметил свои ошибки. Я подумал: "Круто, повреждений не так уж много"

Я действительно ошибался.

Все мои службы (mysql; postregsql; java) больше не могут работать, потому что им нужны зависимости в / и т.д. / альтернативы Запуск

update-alternatives --force --all

Помогите мне немного, но запуск mysql не помогает. Я полностью потерял веру в то, что это исправить, поэтому я хотел бы сделать резервную копию каждого файла конфигурации и выполнить чистую установку моего vps. Но как ты думаешь

У меня нет резервной копии базы данных

Я знаю, что это действительно неправильно, пожалуйста, простите меня.


Мой вопрос

Теперь перейдем к моему вопросу: есть ли способ восстановить соединение PostreSQL и MySQL, чтобы сделать резервную копию базы данных и сохранить ее для выполнения чистой установки на моем VPS? Или я полностью потерялся?

Пока я пробовал:


Ноты

В будущем я сделаю резервную копию, обещаю

Обновить :

Согласно PostreSQL: https://www.postgresql.org/docs/9.1/static/backup-file.html есть способ сделать резервную копию базы данных с помощью fs. Я попробую это


Спасибо, что нашли время, чтобы прочитать меня, надеюсь, у вас есть идея.

Для тех, кто задается вопросом, есть ли решение, я наконец нашел его!

Сначала я скачал gdrive клиент терминала Google Диска.

Затем я сделал несколько резервных копий всех важных каталогов (/ home, / etc / nginx, ...), а для моего сервера MySQL и PostgreSQL я сделал резервную копию следующего каталога:

  • / var / lib / mysql <- для MySQL
  • /var/lib/postgresql/9.3/main <- для PostgreSQL

Я загрузил резервную копию тезисов на свой Google Диск и переустановил свой VPS

Наконец, я переустановил сервер MySQL, остановил демон, сделал резервную копию исходного / var / lib / mysql и загрузил с Google Диска мой старый. И после небольшого исправления разрешения сервер запустился! И вуаля моя база данных вернулась и работоспособна!

Я не тестировал реимпорт данных PostgreSQL, но думаю, что это сработает, попробую завтра.

В любом случае это будет для меня хорошим уроком: несмотря ни на что, всегда выполняйте резервное копирование!

Обновить

Просто завершите импорт моего дампа PostgreSQL, ничего не потеряно!

Помимо настройки ежедневного / ежечасного резервного копирования, всегда рекомендуется создавать резервные копии именно тех папок, с которыми вы собираетесь работать, непосредственно перед тем, как касаться своей системы, и это правило становится еще более важным, если это производственная среда.

В вашем случае я бы посмотрел на mysqldump и эквивалент postgres.

Обычно вы выполняете восстановление из резервной копии или, если потеряны данные критически важны, найдите новую работу.

Как правило, я предлагаю воспользоваться услугой восстановления данных, но для этого необходимо немедленно выключить устройство после аварии. Это также очень дорого и требует много времени.