MySQL ошибка при востановлении из бэкапа

После обновления и перезагрузки сервера заметил, что в roundcub новое письмо создается без адреса отправителя, соответственно профиль пользователя пуст. За эту информацию отвечает таблица identities. Зайдя через phpmyadmin в БД roundcubemail обнаружил, что повреждена таблица identities. Бэкап БД есть, включая эту таблицу.

Создаю таблицу:

CREATE TABLE `identities` (
`identity_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(10) unsigned NOT NULL,
`changed` datetime NOT NULL DEFAULT '1000-01-01 00:00:00',
`del` tinyint(1) NOT NULL DEFAULT '0',
`standard` tinyint(1) NOT NULL DEFAULT '0',
`name` varchar(128) NOT NULL,
`organization` varchar(128) NOT NULL DEFAULT '',
`email` varchar(128) NOT NULL,
`reply-to` varchar(128) NOT NULL DEFAULT '',
`bcc` varchar(128) NOT NULL DEFAULT '',
`signature` longtext,
`html_signature` tinyint(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`identity_id`),
KEY `user_identities_index` (`user_id`,`del`),
KEY `email_identities_index` (`email`,`del`),
CONSTRAINT `user_id_fk_identities` FOREIGN KEY (`user_id`) REFERENCES `users` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=147 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

Выбираю из бэкапа БД нужную таблицу скриптом:

# sed -n -e '/CREATE TABLE.*`identities`/,/CREATE TABLE/p' 2021-03-27.mail_roundcube.sql > identities.dump

где identities имя таблицы в бэкапе 2021-03-27.mail_roundcube.sql и запись данных в файл identities.dump.

НО! При операции ресторе, через phpmyadmin возникала ошибка, что логично.

Поэтому, почистил identities.dump от CREATE TABLE, DROP TABLE отставив только информацию между строками:

LOCK TABLES `identities` WRITE;
/*!40000 ALTER TABLE `identities` DISABLE KEYS */;
INSERT INTO `identities` VALUES (1,1,'2017-12-19 06:43:36',0,1,'acc','','acc@localhost','','',NULL,0),(2,2,'2017-12-19 06:44:09',0,1,'user','','user@lo...................................
/*!40000 ALTER TABLE `identities` ENABLE KEYS */;
UNLOCK TABLES;

Затем через phpmyadmin выбрав БД и таблицу делаю Импорт файла identities.dump. Все.

image_pdfimage_print

ntfs-3g – монтирование флешек

Устанавливаем утилиту, подключив репозиторий:

# yum install epel-release
# yum install ntfs-3g

Смотрим, sdb – нужная флешка:

# lsblk
NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
fd0               2:0    1     4K  0 disk
sda               8:0    0 465,8G  0 disk
├─sda1            8:1    0     1G  0 part /boot
  └─sda2          8:2    0 464,8G  0 part
  ├─centos-root 253:0    0    10G  0 lvm  /
  ├─centos-swap 253:1    0     4G  0 lvm  [SWAP]
  ├─centos-home 253:2    0   300G  0 lvm  /home
  └─centos-ftp  253:3    0 150,8G  0 lvm  /ftp
sdb               8:16   1  14,5G  0 disk
└─sdb1            8:17   1  14,5G  0 part

Монтируем:

# mount -t ntfs-3g /dev/sdb1 /mnt/

Размонтируем:

# umount /mnt
image_pdfimage_print

doveadm – увеличить квоту

Понадобилось увеличить квоту для пользователя, пароля к ящику которого я незнаю.

# doveadm quota get -u username
Quota name         Type    Value     Limit            %
storage=5382813 STORAGE  2411336   3000000           80
storage=5382813 MESSAGE     3210         -            0

Заходим в phpmyadmin, БД postfix, таблица mailbox. Меняем квоту.

Затем в консоли набираем комманду для пересчета:

# doveadm quota recal -u username

Проверяем:

# doveadm quota get -u username 
Quota name         Type    Value     Limit            % 
storage=5382813 STORAGE  2411336   5000000           48
storage=5382813 MESSAGE     3210         -            0

 

image_pdfimage_print

Создание RAID 1 на двух дисках и добавление его в работающую систему

На одном ssd стоит система. Добавили еще два 4Tb диска для NAS. Нужно создать RAID 1. Устанавливаем утилиту:

# yum install mdadm

Сначала необходимо занулить суперблоки на дисках, которые мы будем использовать для построения RAID (если диски ранее использовались, их суперблоки могут содержать служебную информацию о других RAID):

# mdadm --zero-superblock --force /dev/sd{b,c}

* в данном примере мы зануляем суперблоки для дисков sdb и sdc.

Если мы получили ответ:

mdadm: Unrecognised md component device - /dev/sdb
mdadm: Unrecognised md component device - /dev/sdc

что значит, что диски не использовались ранее для RAID. Просто продолжаем настройку.

Далее нужно удалить старые метаданные и подпись на дисках:

# wipefs --all --force /dev/sd{b,c}

Создание рейда

Для сборки избыточного массива применяем следующую команду:

# mdadm --create --verbose /dev/md0 -l 1 -n 2 /dev/sd{b,c}

где:

  • /dev/md0 — устройство RAID, которое появится после сборки;
  • -l 1 — уровень RAID;
  • -n 2 — количество дисков, из которых собирается массив;
  • /dev/sd{b,c} — сборка выполняется из дисков sdb и sdc.

Мы должны увидеть что-то на подобие:

mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: size set to 1046528K

Также система задаст контрольный вопрос, хотим ли мы продолжить и создать RAID — нужно ответить y:

Continue creating array? y

Мы увидим что-то на подобие:

mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

Правим fstab для автозагрузки. Создаем точку монтирования work в корне:

# mkdir /work

# vi /etc/fstab

#
# /etc/fstab
# Created by anaconda on Wed Mar 17 12:15:59 2021
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos-root                   /     xfs  defaults 0 0
UUID=76e2ead1-7b83-4634-9061-5d0ea36312b4 /boot xfs  defaults 0 0
/dev/mapper/centos-home                   /home xfs  defaults 0 0
/dev/mapper/centos-swap                   swap  swap defaults 0 0
/dev/md0                                  /work xfs  defaults 0 0

Монтируем:

# mount -a

Если получим в ответ:

# mount -a /dev/md0 /work
mount: /dev/md0 is write-protected, mounting read-only
mount: unknown filesystem type '(null)'

это значит, нет ни какой файловой системы. Исправляем.

Вводим команду:

# mkfs.xfs /dev/md0
meta-data=/dev/md0 isize=512 agcount=4, agsize=523712 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0, sparse=0
data = bsize=4096 blocks=2094848, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

И опять

# mount -a

Проверяем:

# lsblk

и находим информацию о том, что у наших дисков sdb и sdc появился раздел md0,

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 223,6G 0 disk
├─sda1 8:1 0 1G 0 part /boot
└─sda2 8:2 0 222,6G 0 part
├─centos-root 253:0 0 50G 0 lvm /
├─centos-swap 253:1 0 3,9G 0 lvm [SWAP]
└─centos-home 253:2 0 168,7G 0 lvm /home
sdb 8:16 0 3,7T 0 disk
└─md0 9:0 0 3,7T 0 raid1 /work
sdc 8:32 0 3,7T 0 disk
└─md0 9:0 0 3,7T 0 raid1 /work

Смторим информацию о рейде:

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb[0] sdc[1]
3906886464 blocks super 1.2 [2/2] [UU]
[>....................] resync = 3.0% (117836416/3906886464) finish=665.3min speed=94905K/sec
bitmap: 30/30 pages [120KB], 65536KB chunk

Более подробная информация:

# mdadm -D /dev/md0

/dev/md0:
Version : 1.2
Creation Time : Wed Mar 17 12:50:32 2021
Raid Level : raid1
Array Size : 3906886464 (3.64 TiB 4.00 TB)
Used Dev Size : 3906886464 (3.64 TiB 4.00 TB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Wed Mar 17 13:13:30 2021
State : clean, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : bitmap

Resync Status : 3% complete

Name : kau.imp.kiev.ua:0 (local to host kau.imp.kiev.ua)
UUID : 84cf2972:f7d64647:5cd536ef:0a81a174
Events : 292

Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc

Восстановление RAID

Рассмотрим два варианта восстановлении массива.

Замена диска

В случае выхода из строя одного из дисков массива, команда cat /proc/mdstat покажет следующее:

# cat /proc/mdstat
Personalities : [raid1] 
md0 : active raid1 sdb[0]
      1046528 blocks super 1.2 [2/1] [U_]

* о наличии проблемы нам говорит нижнее подчеркивание вместо U — [U_] вместо [UU].

Или:

# mdadm -D /dev/md0
...
       Update Time : Thu Mar  7 20:20:40 2019
             State : clean, degraded
...

* статус degraded говорит о проблемах с RAID.

Для восстановления, сначала удалим сбойный диск, например:

# mdadm /dev/md0 --remove /dev/sdc

Теперь добавим новый:

# mdadm /dev/md0 --add /dev/sde

Смотрим состояние массива:

# mdadm -D /dev/md0
...
       Update Time : Thu Mar  7 20:57:13 2019
             State : clean, degraded, recovering
...
    Rebuild Status : 40% complete
...

recovering говорит, что RAID восстанавливается; Rebuild Status — текущее состояние восстановления массива (в данном примере он восстановлен на 40%).

Если синхронизация выполняется слишком медленно, можно увеличить ее скорость. Для изменения скорости синхронизации вводим:

# echo '10000' > /proc/sys/dev/raid/speed_limit_min

* по умолчанию скорость speed_limit_min = 1000 Кб, speed_limit_max — 200000 Кб. Для изменения скорости, можно поменять только минимальную.

Пересборка массива

Если нам нужно вернуть ранее разобранный или развалившийся массив из дисков, которые уже входили в состав RAID, вводим:

# mdadm --assemble --scan

* данная команда сама найдет необходимую конфигурацию и восстановит RAID.

Также, мы можем указать, из каких дисков пересобрать массив:

# mdadm --assemble /dev/md0 /dev/sdb /dev/sdc

Запасной диск (Hot Spare)

Если в массиве будет запасной диск для горячей замены, при выходе из строя одного из основных дисков, его место займет запасной.

Диском Hot Spare станет тот, который просто будет добавлен к массиву:

# mdadm /dev/md0 --add /dev/sdd

Информация о массиве изменится, например:

mdadm -D /dev/md0


Number   Major   Minor   RaidDevice State
0       8       16        0      active sync   /dev/sdb
2       8       48        1      active sync   /dev/sdc

3       8       32        –      spare   /dev/sdd

Проверить работоспособность резерва можно вручную, симулировав выход из строя одного из дисков:

mdadm /dev/md0 –fail /dev/sdb

И смотрим состояние:

mdadm -D /dev/md0


Rebuild Status : 37% complete

Number   Major   Minor   RaidDevice State
3       8       32        0      spare rebuilding   /dev/sdd
2       8       48        1      active sync   /dev/sdc

0       8       16        –      faulty   /dev/sdb

* как видим, начинается ребилд. На замену вышедшему из строя sdb встал hot-spare sdd.

 

https://www.dmosk.ru/miniinstruktions.php?mini=mdadm

image_pdfimage_print

rsync – отобразить прогресс

Пришло время замены диска с хранилища (около 2 Тб) и переноса информации со старого на новый. Подключаем диск, форматируем, если нужно разбиваем. Перенос осуществляем при помощи rsync одной командой:

rsync -a --info=progress2 --no-inc-recursive /home/_SRC_ /home/_DST_

–info=progress2 – опция для показа скорости, времени и прогресса.

–no-inc-recursive – отключить инкрементную рекурсию.

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

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

_SRC_ – откуда копировать

_DST_ – куда переносить

image_pdfimage_print

Включение web-сервиса на Mikrotik через SSH

Понадобилось включить web-сервис Mikrotik. Заходим через SSH и выполняем команду:

ip service print

Убеждаемся, что служба www у нас отключена “XI”. Чтобы ее включить выполняем команду:

ip service enable www

и после снова убеждаемся, что сервис стал доступен.

image_pdfimage_print

Проброс порта RDP

Dst. Port – 3389 порт на внешнем интерфейсе ether1 на который будет происходить подключение.

  • accept — просто принимает данные;
  • add-dst-to-address-list — адрес назначения добавляется в список адресов;
  • add-src-to-address-list — исходящий адрес добавляется в соответствующий список адресов;
  • dst-nat — перенаправляет данные из внешней сети в локальную, внутреннюю;
  • jump — разрешает применение правила из другого канала, например при установленном в поле Chain значения srcnat — применить правило для dstnat;
  • log — просто записывает информацию о данных в лог;
  • masquerade — маскарадинг: подмена внутреннего адреса компьютера или другого устройства из локальной сети на адрес маршрутизатора;
  • netmap — создает переадресацию одного набора адресов на другой, действует более расширенно, чем dst-nat. Также Netmap – это преобразование одной подсети в другую 1:1. Как следствие это действие доступно в обоих цепочках NAT (srcnat и dstnat).;
  • passthrough — этот пункт настройки правил пропускается и происходит переход сразу к следующему. Используется для статистики;
  • redirect — данные перенаправляются на другой порт этого же роутера;
  • return — если в этот канал мы попали по правилу jump, то это правило возвращает нас обратно;
  • same — редко используемая настройка один и тех же правил для группы адресов;
  • src-nat — переадресация пакетов из внутренней сети во внешнюю (обратное dst-nat перенаправление).
  • To Address – 10.10.88.56 IP ПК в локальной сети
  • To Ports – 3389 порт на который будет переброшено подключение

Источник: https://lantorg.com/article/probros-portov-na-mikrotik © LanTorg.com

 

image_pdfimage_print