Поиск по этому блогу

Показаны сообщения с ярлыком Работа. Показать все сообщения
Показаны сообщения с ярлыком Работа. Показать все сообщения

вторник, 29 ноября 2016 г.

Пример плохого сценария резервного копирования.

Нужно было по-быстрому организовать резервирование пользовательских файлов в ОС Windows, без привлечения коммерческих продуктов.

1. Подключил smb шару как сетевой диск X:
2. Написал следующий bat сценарий:
@echo off
::присваеваем переменной xcd значение текущей даты в формате подходящем для xcopy
set xcd=%date:~3,2%-%date:~0,2%-%date:~6,4%
::считываем из файла date значение даты создания последней резервной копии
for /f %%i in (X:\date) do set pd=%%i
::если значение даты создания последней резервной копии отсутствует, создаём полную копию, если присутствует резервируем все файлы старше даты создания последней резервной копии
if not defined pd (xcopy "C:\users\username" X:\full\ /Y /V /Z /E /D) else (xcopy "C:\
users\username" X:\%xcd%\ /Y /V /Z /E /D:%pd%)
::передаём файлу
date значение даты создания резервной копии
echo %xcd%>X:\date
exit /b

3. Для сокрытия окна вывода терминала, запускается bat таким jscript:
new ActiveXObject('WScript.Shell').Run('C:\\users\\username\\backup.bat',0,false)

суббота, 10 сентября 2016 г.

понедельник, 14 декабря 2015 г.

Организация удаленого доступа по VNC (RDP) к гостевым системам VirtualBOX без установки Extension Pack

Гарантированно работает на версии 4.3, на остальных не проверялось.
Для начала необходимо остановить машину.
Запускаем поддержку VNC:
vboxmanage modifyvm [vm_name] --vrde on
Указываем пароль для подключения:
vboxmanage modifyvm [vm_name]--vrdeproperty vncppassword=[some_password]
Указываем порт для подключения:
vboxmanage modifyvm [vm_name] --vrdeport [some_port]
Для каждой гостевой системы должен быть отдельный порт.
Подключаемся с помощью любого vnc-клиента, например xtightvncviewer [hv_ip]:[some_port]

перенос гостевой системы VirtualBOX с одного хоста на другой.

Есть два, гипервизора VirtualBOX. Требуется требуется скопировать одну из гостевых ОС с одного хоста, на другой.

На исходном хосте.

  • Сохраняем состояние ВМ - vboxmanage controlvm [vm_name] savestate
  • Экспортируем ВМ в файл OVA - vboxmanage export [vm_name] -o [ova_file_name]
  • Возобновляем работу ВМ - vboxmanage startvm [vm_name] --type headless
  • Копируем файл OVA на целевой хост - scp [local_ova_file_name] [remote_username]@[remote_host]:[remote_ova_file_name]

На целевом хосте:

  • Импортируем ВМ из файла OVA - vboxmanage import [ova_file_name]
  • Запускаем ВМ - vboxmanage startvm [vm_name] --type headless

монтирование smb в linux

sudo mount -t cifs [//HOST/SHARE] [/path/to/local/folder] -o username=[smb_user],password=[smb_pass],uid=[local_user]

  • //HOST/SHARE - хост или ip smb-сервера, а так же наименование ресурса на данном сервере
  • /path/to/local/folder - путь к локальному каталогу, в который будет смонтирован удаленный ресурс
  • smb_user - имя пользователя на smb-сервере, имеющего права доступа к указанному ресурсу
  • smb_pass - пароль пользователя на smb-сервере, имеющего права доступа к указанному ресурсу
  • local_user - имя локального пользователя, которому будет предоставлен доступ к каталогу, в который смонтирован smb-ресурс

суббота, 14 ноября 2015 г.

Восстановление данных с ZFS, на аппаратном рейде 10

Имеется:

Сервер Supermicro 825-7 с шестью SATA дисками ST31000524NS объеденными в RAID 10 средствами интегрированного raid-контроллера.
В качестве ОС установлена FreeBSD 8.2.
На сервере развернут ряд web-сервисов.
Больше никакой информации нет.

Преамбула:

По словам очевидцев. В какой-то момент, сервер перестал загружать ОС, при этом, судя по светодиодной и звуковой индикации один из жестких дисков вышел из строя (при очередной перезагрузке, напротив одного из дисков загорелся красный светодиод и зазвучал длинный звуковой сигнал).
К моменту моего прибытия на место аварии, никакой индикации не наблюдалось, однако ОС все равно не желала загружаться должным образом. Есть предположение, что контроллер автоматически провел ребилд массива и успокоился, однако часть данных все же была потеряна, как потом подтвердится.

Задача:

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

Действия:

Raid-контроллер Adaptec, сообщил, что массив в полном порядке.
В процессе загрузки ОС сообщает, что не может смонтировать корневой раздел и предлагает произвести монтирование вручную, однако при нажатии любой клавиши происходит kernel panic и система зависает намертво.
В качестве загрузочного диска был выбран frenzy-1.4-lite. После загрузки с livecd, gpart list показал, что на жестких дисках имеется три раздела: freebsd-boot, freebd-swap и freebsd-zfs. Судя по размеру, все данные были как раз в zfs. Этот zfs меня несколько напугал, но как всегда, великий и ужасный web, пришел на выручку. К сожалению я не помню на каких именно ресурсах искал нужную информацию, поэтому просто приведу порядок действий.
Команда zdb -l /patch/to/block/device позволяет прочитать так называемые метки zfs, из файла блочного устройства раздела. Там много всякого разного, но меня интересовало только имя пула. Теперь, зная это имя, можно импортировать пул и получить доступ к файловой системе, для этого я использовал такую команду: zpool import -o atlroot=/some/directory POOL_NAME
Теперь раздел zfs доступен для чтения и записи в каталоге /some/directory
На этом все, пытаться восстанавливать загрузку ОС я не стал, так как часть данных все же была утеряна, например в usr не осталось ничего кроме home (что он там вообще делал не знаю, возможно это нормальное положение вещей для FreeBSD), меня интересовали только базы mysql, которые к счастью сохранились в полном объеме, в /var/db/mysql и сайты, которые так же лежали в /var/www/