Утилита Nmap
nmap -v -Pn -p80 192.168.0.1-254
-Pn - не пинговать (считать сервер доступным)
-v verbose
-p80 80 порт
192.168.0.1-254 диапазон с 192.168.0.1 по 192.168.0.254

Название деяния - сканирование портов, в РФ законно
Документация по nmap https://nmap.org/man/ru/

Каретка (^) в командной строке Windows используется:
1. Как символ продолжения строки

dir ^
/ad ^
c:\temp

эквивилентно
dir /ad c:\temp
Поэтому и получается 'HEADYes'
2. Как escape-символ

Т.е. вам надо писать две каретки
git reset --soft HEAD^^

Про сам вордпресс и его код и плагины вам ответили, а по https поясню:
Https нужен для того, что соединение между клиентским устройством (комьютер, телефон и т.п.) и веб-сервером было зашифровано, а значит будут зашифрованы и передаваемые данные.
Что это даёт?
Если вы логинитесь в админку сайта по обычному http, то на пути от вашего устройства до веб-сервера сетевые пакеты можно перехватить и прочитать переданные вами данные (логин, пароль) в открытом виде в виде текста. Если будет использован https, то сетевые пакеты так же перехватываются, но прочитать их содержимое можно только если расшифровать его закрытым ключом, который хранится на веб сервере. Сами сообщения зашифровываются на стороне клиента открытым ключом, который веб-сервер передаёт любому, установившему соединение.
При передаче данных обратно, от сервера к клиенту, используется сгенерированная на клиенте пара открытый-закрытый ключ. Тут уже веб-сервер шифрует сообщения открытым ключам клиента, а клиент расшифровывает их своим закрытым.
Т.е. ключи для расшифровки сообщений текущей сессии знают только клиент и сервер.

И, да, не слушайте Site Developer, где он в комментариях говорит по поводу того, что клиент не знает, что к нему прилетает, потому что как раз клиентское устройство знает, что к нему прилетает.

Как раз недавно искал подобное решение и остановился на backupninja
Умеет по расписанию бэкапить БД и файлы и отправлять их на сторонний сервер разными способами, включая rsync, rdiff, duplicity

В /etc/backup.d/ создаёте конфиги вида 10-db.mysql , 50-ftp.dup
Числа в начале файла описывают очерёдность выполнения в случае одновременного запуска (сначала сдампить базу, а затем заливать из папки с архивом на ftp).
Расширение файла указывает на тип задачи (.mysql - бэкап mysql, .dup - используем duplicity)

Время выполнение бэкапов по-умолчанию задаётся в /etc/backupninja.conf

...
when = everyday at 01:00
...

Его можно переопределить для каждого отдельного бэкапа в начале его конфига

when = sundays at 02:00
when = 30th at 22
when = 30 at 22:00
when = everyday at 01            <-- the default
when = Tuesday at 05:00
when = hourly

Подробнее о конфигах backupninja здесь

Сам duplicity, которым я, например, делаю бэкапы, поддерживает кучу протоколов, в том числе и передачу по ftp. Также поддерживает ротацию бэкапов

Конфиг для duplicity выглядит примерно так:

## Переопределяем время выполнения
when = sundays at 02:00
## Параметры, передаваемые напрямую duplicity при запуске бэкапа
## --no-encryption позволяет отключить шифрование архивов с бэкапом и получить обычный .tar.gz
#options = --no-encryption

testconnect = no
tmpdir = /tmp

[source]
include = /var/backups/mysql
include = /home/user/projects/site1
exclude = /home/user/projects/.git

[gpg]
## Ключ для симметричного шифрования. Duplicity шифрует бэкапы с помощью gpg. Должен быть указан, даже если стоит --no-encryption, хоть и не будет использоваться
password = 123

[dest]
## perform incremental backups
incremental = yes

## days of incremental backups before doing full backup again
increments = 7

## how many days of data to keep
keep = 14

## for how many full backups do we keep their later increments
keepincroffulls = all

desturl = ftp://backup_user@your_backup_server/
ftp_password = backup_user_password

В бэкапах получаются на первый взгляд не очень понятные файлы, типа
duplicity-full-signatures.20130510T160711Z.sigtar.gpg
duplicity-full.20130510T160711Z.manifest.gpg
duplicity-full.20130510T160711Z.vol1.difftar.gpg

Тут можно чуть поподробнее прочитать про них

С бэкапами лучше работать самой утилитой duplicity, но можно и вручную их вытащить. Вручную минус в том, что инкрементальные бэкапы придётся вручную накатывать на полные, когда duplicity сделает это автоматом при указании даты восстановления.
duplicity collection-status src выдаст что-то типа этого

Total number of contained volumes: 3
Type of backup set:                        Time:                        Num volumes:
Full                            Mon Apr 17 00:24:46 2017                 1
Incremental                     Mon Apr 17 01:00:03 2017                 1
Incremental                     Mon Apr 17 09:53:38 2017                 1

после чего можно прочитать содержимое архива на определённую дату
duplicity list-current-files --time 2017-04-17T05:00:00 src (покажет бэкап Mon Apr 17 01:00:03 2017, т.е. ближайший ДО указанного времени)
и восстановить
duplicity restore --time 2017-04-17T05:00:00 src dst

src - это то, где ваши бэкапы хранятся.
Это может быть и локальная директория file:///var/backups//
И ftp ftp://user:password@backup_server//var/backups

Сами файлы хранятся в vol#.difftar.[tar.gz|gpg], если надо вручную вытащить
Если шифровали, то сначала расшифровать .gpg, чтобы получить .tar.gz