Tymczasowy tunel SSH do celów tworzenia kopii zapasowych

Chciałbym napisać skrypt powłoki (obecnie używający bash), aby automatycznie wykonać kopię zapasową zawartości kilku schematów MySQL na zdalnym serwerze. Serwer zdalny jest zablokowany, aby umożliwić dostęp tylko przez SSH, więc muszę utworzyć tunel SSH przed uruchomieniem mysqldumpw różnych schematach.

Mogę utworzyć tunel bez żadnego problemu, jednak chciałbym mieć możliwość automatycznego zamknięcia go po zakończeniu zrzutu bazy danych.

Obecnie mój skrypt robi to:

/usr/bin/ssh -T -f -L 4444:127.0.0.1:3306 -l remoteuser 208.77.188.166 sleep 600

/usr/bin/mysqldump --compress -h 127.0.0.1 -P 4444 -u user -ppassword db1 | gzip > /root/backups/snapshot/db1.sql.gz

/usr/bin/mysqldump --compress -h 127.0.0.1 -P 4444 -u user -ppassword db2 | gzip > /root/backups/snapshot/db2.sql.gz

/usr/bin/mysqldump --compress -h 127.0.0.1 -P 4444 -u user -ppassword db3 | gzip > /root/backups/snapshot/db3.sql.gz

Jeśli połączenie jest utrzymywane otwarte przez 600 sekund, oczywiście jeśli jedno z pierwszych zrzutów zajmie więcej czasu, wówczas połączenie zostanie zamknięte przed zakończeniem pozostałych zrzutów. Chciałbym zachować osobne pliki dla każdej kopii zapasowej schematu (więc na razie --databasesuniknę mysqldump).

Jakieś sugestie?

Nie musisz zawracać sobie głowy tunelowaniem :-).

Po prostu pozwól mysqldump przesyłać strumieniowo dane za pomocą połączenia SSH:

ssh usr@host mysqldump -u dbuser -ppasswd my-database-name >dumpfile

Dodaj opcję -N, opcję -f i tryb uśpienia 600, spowoduje to otwarcie tunelu bez uruchamiania go w tle. Następnie możesz uruchomić polecenie za pomocą &, uzyskać PID, a następnie zabić proces ssh po zakończeniu zadań.

/usr/bin/ssh -T -L 4444:127.0.0.1:3306 -l remoteuser 208.77.188.166 &
PID=$!
do_stuff
kill $PID

(Przetestowałem to za pomocą bash - może być konieczna zmiana rzeczy dla innej powłoki)

Niewielka różnica w sugestii sleske, możesz przesłać wyjście mysqldump przez gzip w celu skompresowania przed przesłaniem:

ssh SSH-USER@SERVER mysqldump -u DB-USER -pDB-PASSWORD DB-NAME | gzip -c > DB-NAME.sql.gz

Jak powiedział Śleske, po co zawracać sobie głowę tym szczególnym przypadkiem? Istnieje jednak rozwiązanie do sterowania tunelem ssh w ogólnym przypadku: użyj nazwanego potoku. Najpierw utwórz fajkę w ten sposób:

ssh -l remoteuser 208.77.188.166 mkfifo /tmp/PIPO

Następnie piszesz (blokowanie do potoku) w ssh, aby utworzyć tunel:

/usr/bin/ssh -T -f -L 4444:127.0.0.1:3306 -l remoteuser 208.77.188.166 "echo T > /tmp/PIPO"

Kiedy chcesz zamknąć tunel, po prostu przeczytaj potok:

ssh -l remoteuser 208.77.188.166 cat /tmp/PIPO

Zrobione!

Tak bym to napisał

scp backup-db.sh remoteuser@208.77.188.166:/root/backups/
ssh remoteuser@208.77.188.166 exec /root/backups/backup-db.sh

Gdzie jest skrypt

#!/bin/sh
# backup-db.sh
DUMPARGS=--compress -h 127.0.0.1 -P 4444 -u user -ppassword
BACKUP_PATH=/root/backups/snapshot

/usr/bin/mysqldump $DUMPARGS db1 | bzip2 > $BACKUP_PATH/db1.sql.bz2
/usr/bin/mysqldump $DUMPARGS db2 | bzip2 > $BACKUP_PATH/db2.sql.bz2
/usr/bin/mysqldump $DUMPARGS db3 | bzip2 > $BACKUP_PATH/db3.sql.bz2

Wreszcie archiwum można scpprzywrócić za pomocą innego polecenia.
Tak, nie prowadziłem rur ani tunelu.