4. И как это выглядит "в натуре"...
- запускаем (по SSH) на VDS хосте скрипт создания и отсылки бэкапов:
Код: Выделить всё
root@277938:~# time ./bacsend
40,2MiB [2,33MiB/s]
1,01GiB [3,16MiB/s]
real 5m44,008s
user 1m17,166s
sys 0m47,270s
- запускаем скрипт приёма на локальном компьютере:
Код: Выделить всё
olej@ACER:~/2019_WORK/own.WORK/rus.linux.net.admin/timeweb$ time ./backreqv
40,2MiB [3,29MiB/s]
1,01GiB [3,17MiB/s]
real 5m38,720s
user 0m3,483s
sys 0m23,328s
Характерно, и это очень важно и на пользу, что если мы перепутаем последовательности 2-х предыдущих операций, запустим 1-м приёмный скрипт на локальном хосте, то получим ошибку, и ничего не будет попорчено:
olej@ACER:~/2019_WORK/own.WORK/rus.linux.net.admin/timeweb$ ./backreqv
(UNKNOWN) [185.178.47.95] 6666 (?) : Connection refused
0,00 B [0,00 B/s]
(UNKNOWN) [185.178.47.95] 6666 (?) : Connection refused
0,00 B [0,00 B/s]
5. Смотрим у себя на локальном хосте:
Код: Выделить всё
olej@ACER:~/2019_WORK/own.WORK/rus.linux.net.admin/timeweb$ ls -l backup-*
-rw-r--r-- 1 olej olej 42163973 янв 2 16:12 backup-02.01.2020_16-11.sql
-rw-r--r-- 1 olej olej 1083973464 янв 2 16:17 backup-02.01.2020_16-11.tgz
Свежие бэкапы здесь!
6. Проверяем на VDS хосте, убеждаемся что промежуточные файлы бэкапов, занимающие много места, на сервере не создавались и не сохранялись:
Код: Выделить всё
root@277938:~# uptime
17:24:12 up 5 days, 23:28, 5 users, load average: 0,00, 0,18, 0,23
Код: Выделить всё
root@277938:~# df | grep ^'/dev/'
/dev/vda1 5092992 3617220 1197348 76% /
root@277938:~# du -hs /var/www/linux-ru.ru/
1,2G /var/www/linux-ru.ru/
root@277938:~# ls -l /var/www/
итого 8
drwxr-xr-x 2 root root 4096 дек 20 23:20 html
drwxr-xr-x 25 www-data www-data 4096 дек 22 22:16 linux-ru.ru