Перенос базы на другой жёсткий диск¶
Жёсткий диск/раздел должен существовать в системе и быть подключен физически. Перенос базы данных выглядит так:
Внимание
Нельзя использовать одну и ту же точку монтирования для файлов и БД.
Если на диске есть требуемые разделы, переходим к п. 2.
Примечание
cfdisk - работает только с MBR разделами. Если ваш жёсткий диск больше 2 Тб, вам нужно использовать GPT разделы!
Если разделов нет - размечаем диск своей любимой программой разметки, например так:
sudo cfdisk /dev/sdX
и создаём на нём файловую систему командой
sudo mkfs.ext4 /dev/sdX
где Х - это завершение имени диска.
Останавливаем сервисы командами:
sudo service postgresql stop
sudo service staffcop stop
sudo service nginx stop
Редактируем файл /etc/fstab
sudo nano -w /etc/fstab
Прописываем туда следующую строку:
/dev/sdX /var/lib/postgresql/ ext4 rw,noatime 0 2
Где /dev/sdX - ваш жёсткий диск, /var/lib/postgresql/ - каталог, в котором будет отображаться содержимое диска, ext4 - тип файловой системы (если вы используете другую фс - jfs/xfs/reiser и т.д. эта опция меняется.) rw - означает разрешение на чтение-запись на диск. Также можно прописывать диск по UUID. Получить UUID диска можно командой:
sudo blkid
В этом случае первая часть записи примет вид UUID= , где в кавычки нужно вписать резальтат вывод вышеуказанной команды.
Предупреждение
Разделы с GPT-форматированием можно примонтировать только по UUID-диска!
Создаём папку для резервного копирования, и перемещаем данные из каталога базы данных туда.
mkdir /home/user/rezerv && sudo mv /var/lib/postgresql/* /home/user/rezerv
Где user - это домашний каталог пользователя, скорее всего, у вас он отличается. Узнать домашний каталог пользователя можно командой
env | grep -E "home|HOME"
результатом выдачи данной команды будет домашний каталог пользователя, от имени которого эта команда выполнена.
Проверяем корректность монтирования командой
sudo mount -a
эта команда монтирует диск, который уже прописан в fstab, но еще не примонтирован.
Соответственно, если мы что-то вписали неверно либо ошиблись, то мы увидим ошибки монтирования, и, соответственно, получим возможность исправить допущенную ошибку. Проверяем корректность монтирования диска командой типа
df -h
Также можно проверить, что данный раздел доступен на запись. Например, создадим текстовый файл и проверим его наличие командами
touch /var/lib/postgresql/11/main/test_write.txt && ls -l /var/lib/postgresql/11/main/
Либо просто выполнив команду mount без параметров: ее результатом станет вывод всех монтированных систем; наше новое устройство должно быть монтировано rw.
Копируем всё на жд,
sudo cp -R /home/user/rezerv/* /var/lib/postgresql/
В случае, если вы перемещали данные в другой каталог, произведите изменения в соответствии с реальным расположением файлов.
Меняем владельца на postgres.
sudo chown -R postgres:postgres /var/lib/postgresql/11/main
Выставляем ему права доступа на 700.
sudo chmod -R 700 /var/lib/postgresql/11/main
Запускаем сервисы postgresql, staffcop и nginx.
sudo service postgresql start
sudo service staffcop start
sudo service nginx start
Выполняем команду
sudo staffcop sql
в появившемся приглашении пишем analyze; ждём.
ошибки типа «ПРЕДУПРЕЖДЕНИЕ: «pg_shdescription» пропускается — только суперпользователь может анализировать этот объект» не критичны, т.к. говорят о том, что команда, запущенная с данными правами, не смогла проанализировать служебные таблицы БД. Это и не требуется.
Заходим в веб-интерфейс, проверяем что всё работает, все отчёты видны и тд. Если всё в порядке, можно удалять резервные файлы
rm -R /home/user/rezerv
Как и любой rm следует применять с осторожностью.