Estoy intentando hacer una copia de seguridad remota detrás de un firewall. Realmente no hay problema en dividir esto en su propio script que se llama en crontab, ¡pero eso no es nada divertido! Lo que estoy tratando de hacer con:
pg_dump -U my_user my_database | ssh me@myserver "> backup.sql"
es hacer una copia de seguridad de una base de datos postgresql (vuelca todo a la salida estándar) y redirigirla a un comando ssh remoto que simplemente la coloca en backup.sql.
Desafortunadamente, todo lo que obtengo es un "backup.sql" vacío en mi caja remota. La redirección no es mi punto fuerte, por lo que agradecería cualquier consejo. gracias.
Respuesta1
intentar
pg_dump -U my_user my_database | ssh me@myserver "cat > backup.sql"
Respuesta2
Aún mejor: comprímalo antes de SSH:
pg_dump -U my_user my_database | gzip -c | ssh me@myserver "cat > backup.sql.gz"
Esto ahorra una gran cantidad de ancho de banda con volcados de SQL.
De hecho, lo hago al revés. Hago que el servidor de respaldo inicie sesión en el servidor del que se realizará la copia de seguridad. Esto significa que si cualquier servidor (aparte del servidor de respaldo, que tiene una seguridad seriamente fascista) se viera comprometido en el nivel raíz, el servidor de respaldo y, por lo tanto, todos los demás servidores. - no se ve comprometido de forma predeterminada.
Por lo tanto, mi comando para realizar el volcado de SQL de forma remota es un poco diferente:
ssh <server> "pg_dump -U <user> <database> | gzip -c" > /backups/sqlbackup.sql.gz
Preste especial atención a dónde están las comillas: definen lo que se ejecuta en el extremo remoto y lo que se ejecuta localmente.