16.1.23

skillpipe

 https://www.skillpipe.com/

Running a command as Administrator using PowerShell?

 PS> Start-Process powershell -Verb runAs



https://stackoverflow.com/questions/7690994/running-a-command-as-administrator-using-powershell

Копирование и восстановление баз данных в Microsoft SQL Server 2012 / 2008

 

1. Причины потери данных

Можно выделить 5 основных причин потери данных:

  1. Программные ошибки — Возникновение условий, приводящих к аварийному завершению системы. Поскольку такие ошибки основываются на дефектах программной логики, система баз данных не может выполнить восстановление в подобных ситуациях. Поэтому восстановление должен проводить сам программист, выполнив обработку таких исключений.
  2. Ошибки администратора (человеческий фактор) — Случаи, в которых пользователь с большими полномочиями может неумышленно (или умышленно) разрушить данные. Необходимо постараться создать такой режим работы, который сделает подобную ситуацию маловероятной, однако совсем исключать такую возможность нельзя.
  3. Выход из строя компьютера (сбой системы) — Возникает в результате ошибок в оборудовании и программном обеспечении. В этом случае содержимое оперативной памяти компьютера может быть потерянно. В качестве защиты, можно рекомендовать использование резервного сервера, зеркальное отображение баз данных и пр.
  4. Отказ дискового накопителя — Физическое разрушение жесткого диска. Рекомендуется использование технологий RAID для хранения файлов баз данных, кроме того необходимо, чтобы файлы резервных копий хранились на дисковом носителе, отличным от устройства, на котором располагаются файлы баз данных.
  5. Катастрофы (пожар, наводнение, землетрясение) или кража — Обойти эту ситуацию станет возможным, если устройство, содержащее необходимую для восстановления данных информацию, будет храниться отдельно от основного оборудования и не будет потеряно в результате катастроф или краж.

Необходимо постараться создать систему резервного копирования, позволяющую восстановить данные в любой из описанных выше ситуаций.

2. Типы резервного копирования

Существует 2 режима создания резервных копий:

  1. Статическое резервное копирование — режим, при котором в процессе создания копии только одна активная сессия, поддерживаемая системой, является той сессией, которая создает резервную копию. Другие пользовательские процессы во время выполнения копирования недопустимы.
  2. Динамическое резервное копирование — режим, при котором копирование баз данных может выполняться без остановки сервера баз данных, удаления пользователей или даже закрытия файлов. Пользователи могут и не знать, что выполняется процесс резервного копирования.

MS SQL Server поддерживает оба режима создания резервных копий.

3. Модели восстановления баз данных

Выбор модели восстановления базы данных определяет объем данных, который может быть потерян во время разрушения базы данных, а также скорость использования, размер резервной копии протокола транзакций и период времени, необходимый для резервного копирования протокола. MS SQL Server поддерживает три модели восстановления:

  1. Полная модель восстановления — модель, при которой все операции записываются в протокол транзакций. Поэтому эта модель предоставляет полную защиту против сбоев внешних устройств.
    • Преимущества:
      1. Есть возможность восстановить базу данных с последней подтвержденной транзакции, которая была сохранена в файле протокола.
      2. Возможно восстановить данные на любой момент времени.
      3. Возможно восстановить данные на отметку в протоколе. Отметки в протоколе соответствуют заданной транзакции и добавляются только если эта транзакция подтверждается.
      4. Протоколируются все операции, связанные с изменением индекса. В этом случае пересоздание индекса выполняется быстрее, потому что не надо создавать их заново.
    • Недостатки:
      1. Соответствующий протокол транзакций может быть очень большим по объему, и файлы на диске, содержащие этот протокол, могут увеличиваться в размере очень быстро. В связи с этим возможно заполнение протокола транзакций.
      2. Протокол транзакций должен быть защищен от сбоев внешних устройств. По этой причине использование технологии RAID для защиты протокола транзакций строго рекомендуется.
      3. Требуется значительно больше времени на резервное копирование.
    • Заключение:
      Данная модель восстановления рекомендована для производственных баз данных, если позволяет аппаратная часть сервера баз данных.
  2. Модель восстановления с неполным протоколированием — То же, что и полная модель восстановления, за тем исключением, что не ведется протоколирование массовых или bulk-операций. А резервные копии протокола транзакций содержат в этом случае результат такой операции.
    • Преимущества:
      1. Как и с полной моделью восстановления, есть возможность восстановить базу данных с последней подтвержденной транзакции, которая была сохранена в файле протокола.
      2. Возможно восстановить данные на любой момент времени, если не выполнялось объемных операций.
      3. Возможно восстановить данные на отметку в протоколе, если не было объемных операций.
      4. Объемные операции выполняются намного быстрее, чем под полной моделью восстановления, так как они не протоколируются.
      5. Для резервной копии протокола требуется гораздо меньше памяти, чем в случае полного восстановления.
    • Недостатки:
      1. Те же, что и при полной модели восстановления.
      2. Не протоколируется операции с изменением индекса. При восстановлении, индексы потребуется создать заново.
      3. Восстановление с резервной копии протокола дольше, нежели при полной модели восстановления.
      4. Нет возможности восстановить данные на момент времени или на отметку в протоколе в случае объемных операций.
    • Заключение:
      Модель восстановления с неполным протоколированием используется для производственных баз данных в тех случаях, когда периодически происходят крупномасштабные или объемные bulk-операции.
  3. Простая модель восстановления — В простой модели восстановления протокол транзакций усекается, если появляется точка восстановления. Но это не означает, что вообще не существует протоколирования, содержимое протокола используется во время создания контрольной точки, где все транзакции протокола подтверждены или для них выполнен откат.
    • Преимущества:
      1. Производительность всех объемных операций очень высокая.
      2. Низкие требования к объему памяти протокола.
    • Недостатки:
      1. Данные возможно восстановить только на момент последнего резервного копирования, а значит недопустимы восстановления на конкретный момент времени или на отметку в протоколе. Все изменения с последнего резервного копирования должны быть восстановлены вручную.
    • Заключение:
      Рекомендуется использовать простую модель восстановления для производственных баз, только в тех случаях, когда сервер баз данных не обладает достаточным объемом памяти или когда аппаратная часть сервера баз данных ниже рекомендуемой.

4. Методы резервного копирования

MS SQL Server предоставляет 4 различных метода резервного копирования:

  1. Полное копирование базы данных (Full) — При полном резервном копировании создается резервная копия всей базы данных целиком, она включает в себя схему всех таблиц, соответствующие файловые структуры, а также содержит все данные из этой базы на момент завершения резервного копирования. Это осуществляется благодаря тому, что полное копирование захватывает состояние базы данных на момент начала копирования. А затем, если копирование выполняется динамически, система записывает любые действия, которые имеют место в процессе создания копии.
    • Преимущества:
      Быстрая скорость восстановление базы данных.
    • Недостатки:
      Полное резервное копирование требует больше времени и требует больше пространства для хранения, чем другие методы копирования.
    • Заключение:
      Для небольших баз данных, которые можно скопировать быстро, лучше всего применять полное резервное копирование. Но для больших баз требуется кроме полных резервных копий, создавать также и дифференцированные (разностные) копии баз данных.
  2. Дифференцированное (разностное) резервное копирование (Differential) — В этом случае создается копия только частей баз данных, которые менялись с момента последнего полного копирования баз данных. Эта полная резервная копия называется основой для разностной копии. Как и в случае полного резервного копирования, любые действия, имеющие место во время создания копии, также копируются.
    • Преимущества:
      Этот тип резервного копирования минимизирует время, требуемое для копирования, т. к. количество копируемых данных значительно меньше, чем при полном копировании.
    • Недостатки:
      Для восстановления необходимо загрузить сначала полную копию баз данных, а затем разностную, что занимает больше времени. И, соответственно, нет смысла применять разностное копирование без полного.
    • Заключение:
      Используется на больших базах данных в связке с полным резервным копированием.
  3. Резервное копирование протокола транзакций (Transaction log) — Данный вид копирования применяется при полной модели восстановления (или при неполном протоколировании) баз данных, и учитывает только изменения, записанные в протокол транзакций. Поэтому такая форма резервного копирования не основывается на физических страницах баз данных, а только на логических операциях.
    • Преимущества:
      1. Самая быстрая скорость создания копии.
      2. В отличии от дифференцированных резервных копий, где возможно восстановить базу данных только на момент последнего копирования, позволяет восстановить базу данных на конкретный момент времени.
      3. Правильное «закрытие» протокола транзакций перед началом новой порции действий с этим протоколом. Одна из наиболее общих ошибок системы возникает, когда переполняется протокол транзакций. Если память, используемая для протокола транзакций, заполняется на 100%, то система должна остановить все выполняющие транзакции, пока память не будет освобождена. Эта проблема может быть устранена только при частом выполнении резервного копирования протокола транзакций: каждый раз происходит «закрытие» порции существующего протокола и сохранение на другом внешнем устройстве. Эта порция протокола становится повторно используемой, следовательно, система восстанавливает дисковое пространство.
    • Недостатки:
      Более долгий процесс восстановления, чем при дифференцированном резервном копировании, где требуется полная копия базы данных и последняя разностная копия, в данном случае потребуется полная копия и все существующие копии протоколов транзакций.
    • Заключение:
      Рекомендуется применять на производственных базах данных в связке с полным резервным копированием.
  4. Резервное копирование файлов или файловых групп — Данный метод позволяет копировать указанные файлы баз данных вместо копирования всей базы данных. Отдельные файлы могут быть восстановлены из копии, позволяя выполнить восстановление после сбоя, который повлиял лишь на небольшое подмножество файлов баз данных.
    •  Заключение:
      Копирование файлов базы данных рекомендуется выполнять только когда база данных является очень большой, и нет достаточно времени для полного копирования базы данных.

5. Какие базы данных и как часто копировать?

  1.  База данных master является наиболее важной базой данных системы, потому что она содержит информацию обо всех базах данных в этой системе. Поэтому резервное копирование базы данных master должно происходить на регулярной основе. Кроме того, рекомендуется создавать копию каждый раз, когда выполняются действия, приводящие к модификации базы данных master. Вот некоторые из них:
    • Выполнение операторов и хранимых процедур;
    • Создание, изменение и удаление базы данных;
    • Изменения протокола транзакций.
  2. Следует выполнять резервное копирование всех производственных баз данных на регулярной основе. Дополнительно, необходимо делать резервную копию после того как с базами данных были выполнены следующие изменения:
    • После создания базы данных;
    • После создания индексов;
    • После создания протокола транзакций;
    • После выполнения непротоколируемых операций (операции, которые не записываются в протокол транзакций).

6. Пример стратегии резервного копирования

Ниже приводится некоторый план резервного копирования, в реальной организации:
Plan_rezerv_kopirovaniya_01

И некоторые характеристики связанные с выполнением резервного копирования базы данных DB1:

Аппаратная часть:

    • Процессор Opteron 8220 8×1.0 Ghz
    • ОЗУ 24 Гб
    • HDD 250 Гб RAID 1+0

Программное обеспечение:

Базы данных:

    • Общий объем баз данных: ~ 95 Гб
    • Объем базы данных master: ~ 5 Мб
    • Объем базы данных DB1: ~ 23 Гб
    • Модель восстановления базы данных DB1: Полная
    • Прирост базы данных DB1 в день: ~ 200 Мб

Резервные копии базы данных DB1:

    • Время создания полной резервной копии: ~ 5 мин.
    • Время создания копии протокола транзакций: ~ 4 сек.
    • Размер полной резервной копии (с сжатием): ~ 1,6 Гб
    • Размер копии протокола транзакций: ~ 20 Мб

Необходимое дисковое пространство для плана резервного копирования DB1:

    • Хранение полных резервных копий (1 месяц): ~ 50 Гб
    • Хранение копий протокола транзакций (1 месяц): ~ 10 Гб
    • Хранение полных копий от 1-ого числа каждого месяца (1 год): ~ 20 Гб
    • Итого размер дискового пространства: ~ 80 Гб
    • Итого размер дискового пространства в % от размера базы: ~ 350 %

Время восстановления базы данных DB1:

    • Время восстановления полной резервной копии: ~ 5 мин.
    • Время восстановления копии протокола транзакций: ~ 5 сек.


Что такое VLAN?

 VLAN (Virtual Local Area Network, виртуальная локальная сеть) — это функция в роутерах и коммутаторах, позволяющая на одном физическом сетевом интерфейсе (Ethernet, Wi-Fi интерфейсе) создать несколько виртуальных локальных сетей. VLAN используют для создания логической топологии сети, которая никак не зависит от физической топологии.

Примеры использования VLAN

  • Объединение в единую сеть компьютеров, подключенных к разным коммутаторам.
    Допустим, у вас есть компьютеры, которые подключены к разным свитчам, но их нужно объединить в одну сеть. Одни компьютеры мы объединим в виртуальную локальную сеть VLAN 1, а другие — в сеть VLAN 2. Благодаря функции VLAN компьютеры в каждой виртуальной сети будут работать, словно подключены к одному и тому же свитчу. Компьютеры из разных виртуальных сетей VLAN 1 и VLAN 2 будут невидимы друг для друга.

Объединение VLAN

 

  • Разделение в разные подсети компьютеров, подключенных к одному коммутатору.
    На рисунке компьютеры физически подключены к одному свитчу, но разделены в разные виртуальные сети VLAN 1 и VLAN 2. Компьютеры из разных виртуальных подсетей будут невидимы друг для друга.

Разделение VLAN

 

  • Разделение гостевой Wi-Fi сети и Wi-Fi сети предприятия.
    На рисунке к роутеру подключена физически одна Wi-Fi точка доступа. На точке созданы две виртуальные Wi-Fi точки с названиями HotSpot и Office. К HotSpot будут подключаться по Wi-Fi гостевые ноутбуки для доступа к интернету, а к Office — ноутбуки предприятия. В целях безопасности необходимо, чтобы гостевые ноутбуки не имели доступ к сети предприятия. Для этого компьютеры предприятия и виртуальная Wi-Fi точка Office объединены в виртуальную локальную сеть VLAN 1, а гостевые ноутбуки будут находиться в виртуальной сети VLAN 2. Гостевые ноутбуки из сети VLAN 2 не будут иметь доступ к сети предприятия VLAN 1.

Разеделение Wi-Fi VLAN

 

Достоинства использования VLAN

  • Гибкое разделение устройств на группы
    Как правило, одному VLAN соответствует одна подсеть. Компьютеры, находящиеся в разных VLAN, будут изолированы друг от друга. Также можно объединить в одну виртуальную сеть компьютеры, подключенные к разным коммутаторам.
  • Уменьшение широковещательного трафика в сети
    Каждый VLAN представляет отдельный широковещательный домен. Широковещательный трафик не будет транслироваться между разными VLAN. Если на разных коммутаторах настроить один и тот же VLAN, то порты разных коммутаторов будут образовывать один широковещательный домен.
  • Увеличение безопасности и управляемости сети
    В сети, разбитой на виртуальные подсети, удобно применять политики и правила безопасности для каждого VLAN. Политика будет применена к целой подсети, а не к отдельному устройству.
  • Уменьшение количества оборудования и сетевого кабеля
    Для создания новой виртуальной локальной сети не требуется покупка коммутатора и прокладка сетевого кабеля. Однако вы должны использовать более дорогие управляемые коммутаторы с поддержкой VLAN.

The Jimi Hendrix Experience - Voodoo Child (Slight Return)

9.1.23

How to reset PrestaShop admin password

 

If you need to reset your PrestaShop admin password, you may simply use the I forgot my password option. For this, please do the following:


1. Open your PrestaShop administrative URL.

When you installed PrestaShop, you were asked to create an administrative folder. So, the URL for PrestaShop administrative login page looks like http://yourdomain.com/adminfoldername/.

2. Once you’ve opened the login page, press the I forgot my password button:



3. Fill in your administrative email address that was set during the installation of PrestaShop and press Send. You will see a pop-up message telling you that the new password has been sent to your email:



4. Log into your contact email address and check the inbox. The email with your new password should be there.

5. Get back to the PrestaShop login page and use your new password to log in.


If you do not receive the confirmation email, you may reset your PrestaShop password through the MySQL database using the phpmyadmin tool in cPanel.

1. Log into your cPanel account.
2. Find phpmyadmin menu and click on it:



3. From the left-side list select the database which stands for your PrestaShop installation and click on it:



4. If you don’t know which database stands for your PrestaShop, you can find this information in a special config file.

For Prestashop 1.6 and earlier: log into your cPanel and open the File Manager menu. Navigate to the folder where your PrestaShop is installed and open the /config/ folder. The configuration file is placed in this folder under the name of settings.inc.php. Open it and get the database name from there (you may find it in the _DB_NAME_ field).

You also need to copy-paste the _COOKIE_KEY_ from this page. You will need it later for the password resetting:



For Prestashop 1.7, the config file can be found under the following path: root folder of your Prestashop installation/app/config/parameters.php.

5. Tables are usually sorted by alphabet. Find the ps_employee table and click on it:



6. Now you see the users list. Choose the user you need and press Edit:



7. In the passwd line choose MD5 from the drop-down menu. Copy-paste the _COOKIE_KEY_ from your settings.inc.php file into the Value field.
Once the key is copy-pasted, please scroll to the end of the line and enter your password right after the key, without the space after the key. Press Go:






That's it!