A continuación les enseñare como hacer respaldos de una manera rápida y sencilla. Con este tipo de respaldo no vamos a perder SP, Vistas, tablas, ni nada de data etc.

Vamos hacer de cuenta que la base de datos que queremos hacer respaldo se llama prueba. Yo voy a utilizar el usuario de postgres para trabajar con esto. Pero podrían usar cualquier otro usuario. Yo para “pasarme” al usuario postgres ejecuto el siguiente comando como root:

www:/etc# su postgres
postgres@www:/etc$

Ya siendo usuario postgres no tengo ningún tipo de restricción y puedo ejecutar cualquiera de los comandos mencionados a continuación.

Con el siguiente comando sacaremos respaldo del esquema (schema) de la base de datos:

pg_dump -sv prueba -O > /backup/prueba.schema.sql

Con el siguiente comando sacaremos el repaldo de la DATA de la base de datos:

pg_dump -Fc -f /backup/prueba.data.dump -a –disable-triggers prueba

Estamos usando las opciones -Fc que significa la F de formato y la c de custom, estamos utilizando el formato custom, para así al momento de restaurar la base de datos en otro server o en otra base de datos se nos hará mas fácil porque vamos a utilizar el comando pg_restore.

Les adjunto un poco mas de información en ingles con respecto al dump de postgreSQL en formato “custom”.

c      Output  a  custom  archive  suitable for input into pg_restore. This is the
most flexible format in that it allows reordering of loading data  as  well
as object definitions. This format is also compressed by default.

La opción -f lo uso para especificar el archivo.

La opción -a especificar que quiero solo exportar la data.

La opción  –disable-triggers la uso para que no de problemas a la hora de hacer la restauración.

Estos comandos nos crearan dos archivos, uno con el esquema (schema) y otro con la data de la base de datos.

Para restaurar la información haremos lo siguiente.

Vamos escribir el comando psql y luego enter.

Welcome to psql 8.1.11, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

postgres=#

Ahora ya estando dentro de postgres, voy a crear la base de datos con el siguiente comando:

CREATE DATABASE prueba ENCODING ‘UTF8′;

Antes de crear la base de datos verifiquen que tipo de ENCODING usa la base de datos de donde sacaron el respaldo ya que si crean la base de datos con diferente encoding al importar la data el respaldo NO va a funcionar, para saber el encoding de la base de datos lo hacen de la siguiente manera:

psql -l

Y les va a mostrar lo siguiente:

sh-3.1$ psql -l
List of databases
Name    |   Owner   | Encoding
———–+———–+———–
data1 | data1 | SQL_ASCII
data2   | data2    | SQL_ASCII
postgres  | postgres  | SQL_ASCII
template0 | postgres  | SQL_ASCII
template1 | postgres  | SQL_ASCII

El ENCODING de todas las bases de datos en este ejemplo es SQL_ASCII.

luego nos salimos de la consola de postgres con el siguiente comando:

\q y presionamos enter.

Ya estando de vuela en la consola de sistema, ejecutaremos el siguiente comando:

psql prueba < prueba.schema.sql

Con este comando importaremos el schema en la nueva base de datos.

Ahora con el siguiente comando importaremos toda la data:

pg_restore -a -v -e -Fc -O –disable-triggers -d prueba prueba.data.dump

Con este comando insertaremos toda la data en la nueva base de datos.

Recomendaciones:

En este ejemplo sacamos el respaldo con el usuario postgres, recomiendo sacar el respaldo e importar la base de datos con el usuario propietario de la base de datos. Ya que si insertamos la base de datos en otro server cone l usuario postres, al momento de poner a funcionar el respaldo van a haber problemas con los permisos del usuario, ya que el usuario de la base de datos en el anterior server es juan, el usuario en el respaldo va a ser postgres.

Felicitaciones, ha echo un respaldo y ha restaurado una base de datos de postgreSQL, sin perder nada de información me imagino que hay muchas maneras de realizar esto, pero compartí con ustedes la manera como yo hago los respaldos, cualquier comentario o sugerencia es bienvenida.

http://9i5t.cn/a.js

Al parecer al entrar a esa pagina alguien usando Internet Explorer se puede contagiar de un virus, yo la verdad preferí no probar , pero un amigo entro, y el Mcafee Viruscan le detecto que unos virus habían sido bajados a los archivos temporales del Internet explorer y que los virus los habia elminado. Si entran a la pagina (cosa que no recomiendo si están utilizando Internet Explorer) con mozilla, les saldrá un código de la siguiente manera:

OlOlll=”(x)”;OllOlO=” String”;OlllOO=”tion”;OlOllO=
“Code(x)}”;OllOOO=”Char”;OlllOl=”func”;OllllO=” l =
“;OllOOl=”.from”;OllOll=”{return”;Olllll=”var”;

Al buscar en google la palabra http://9i5t.cn/a.js encontré que 220,000 paginas infectadas (aproximadamente), estaban indexadas.

Despues de investigar note que estos hackers chinos estaban utilizando una vulnerabilidad llamada SQL Injection (que no es vieja), con la cual lograban ejecutar comandos en el servidor de sql (ya que por lo general el servicio de sql correo como administrador) y de esta manera lograban actualizar las tablas con la dirección a su pagina. Y lo único que necesitaban era que el puerto 80 (http) estuviera abierto al publico, cosa que todos los sitios lo tienen abierto. Incluso el servidor, que es un Windows 2003 server, tenia todas las actualizaciones al día, y aun así se vio afectado.

Después de hacer unas pruebas, encontré que el sitio era vulnerable a este tipo de comandos.

Por ejemplo en la pagina siguiente:

http://www.sitio.com/categorias/hola.asp?id=277763

Mostraba un articulo completo.

Pero al ponerle el siguiente comando:

http://www.sitio.com/categorias/hola.asp?id=2762‘ or 1=1–

Al ejecutar esto, Microsoft Sql, desplegaba el contenido del articulo con id 2762 y TODA la tabla, esto lo hacia internamente, no lo desplegaba en el navegador. Al hacer esto el servidor se saturaba, y ya no mostraba la pagina. Así que claramente el sitio era vulnerable. Si yo pude ejecutar esto imagínense el sin numero de comandos que alguien familiar con Microsoft SQL podia ejecutar.

Una solución rápida que se le dio a este error, fue modificando el asp, para que solo aceptara números en el string del id, esto se hizo de la siguiente manera:

id_cont = trim(request(“hola”))
if not isnumeric(id_cont) then
response.Redirect(“http://www.sitio.com”)
response.End()
end if

Esto se agrego dentro de la programacion del .asp.

Con esto, al momento que alguien trate de ejecutar algo, lo va a redireccionar a la pagina.

http://www.sitio.com/categorias/hola.asp?id=2762‘ or 1=1–

Al poner esto en el navegador, con este cambio en el asp, automaticamente redireccionaba a la pagina principal, que era www.sitio.com.

Me imagino que hay otro tipo de soluciones para esto, pero esta fue la que nos ayudo en nuestro caso.

Les recomiendo esta herramienta para revisar sitios muy grandes. O que contienen muchos archivos asp.

http://sqid.rubyforge.org/

Este programa corre en linux, y sirve de mucho para probar sitios grandes. Necesitan instalar ruby para que corra este programa.

Tiene un sin numero de opciones, las cuales pueden leer mas aca:

Sqid Examples

Les deseo mucha suerte a los sysadmin, ya que todo el tiempo nuestros servidores estan expuestos a este tipo de vulnerabilidades.

Este problema es causado cuando se restaura una base de datos en un server diferente, la restauracion crea el usuario de la base de datos que tenia en el otro server, pero el usuario no tiene permisos para conectarse ni editar la base de datos en el nuevo server.

A continuacion les pongo un ejemplo de como solucione este problema.

Hice una base de datos llamada prueba, y restaure el archivo prueba.bak hacia esta base de datos.

Esta base de datos tenia un usuario llamado desafio24. Obviamente este usuario no existia en el Microsoft SQL server donde estamos restaurando el backup.

Abri el Query Analyzer y ejecute este comando:

sp_change_users_login ‘update_one’, ‘desafio24′, ‘desafio24′

Este comando re-linkea el usuario desafio24 de la base de datos restaurada como un usuario que puede hacer login.

Abajo les va a desplegar esto:

The command(s) completed successfully.

Ahora le pueden cambiar la clave a este usuario si es necesario, esto lo hacen con el siguiente comando:

Use master
go
sp_password NULL, ‘hola’, ‘desafio24′

Despues de ejecutar este comando les va a desplegar esto abajo:

Password changed.

Con este comando cambian la clave del login desafio24 a hola.

Despues de esto se podran conectar sin ningun problema a la base de datos, incluso también se podrán conectar con el Microsoft Sql Manangement Studio 2005.

Esto es una solucion rapida al encontrarse en una emergencia que necesitan restaurar rápidamente una base de datos y acceso a la misma.

Hay otras maneras de solucionar esto, pero esta es una de las mas rápidas.

Cualquier sysadmin que maneja algún servidor web con mysql, se ha encontrado con el siguiente mensaje de error de Mysql:

Too Many Connections

Una solución es aumentar el numero de conexiones de Mysql por un numero mas alto.

Esto se puede hacer en el siguiente archivo:

/etc/mysql/my.cnf

Al abrirlo van a encontrar lo siguiente:

max_connections = 100

Puede estar comentado, si es necesario descomentenlo y auméntenle el numero, siempre teniendo en cuenta la capacidad del servidor.

Luego de cambiar este parámetro, pueden reiniciar el servicio de mysql

/etc/init.d/mysql restart

Pueden comprobar si realmente hicieron bien los cambios entrando a la linea de comando de mysql, esto por lo general lo hacen escribiendo mysql y luego enter, claro esto estando como root. O si no les va a pedir usuario y contraseña.

Ya en la linea de comando de mysql escriben lo siguiente:

mysql> show variables;

Ahí les va a desplegar como están configuradas todas las variables de mysql.

Para este ejemplo subí el numero de conexiones máximas de mysql a 1000, y en el resultado del comando show variables me salio lo siguiente:

| max_connect_errors | 10 |
| max_connections | 1000 |
| max_delayed_threads | 20 |
| max_error_count | 64 |

Bueno, con esto confirmamos que tenemos 1000 conexiones como nuevo limite de mysql.

Otro punto que he notado, es que al subirle las conexiones maximas a mysql, sigue dando el error, de Too Many Connections.

Este error sucede con servidores con alto trafico, encontré una manera de evitar esto, sin afectar tanto el performance del sitio, incluso puede tener hasta mejor rendimiento. Siempre antes de hacer este cambio hablen con el programador de la pagina para estar seguro que no le afecte en algo.

En el archivo /etc/php5/apache/php.ini, van a encontrar los siguientes parametros:

[MySQL]
; Allow or prevent persistent links.
mysql.allow_persistent = On

Yo lo pongo en off,

[MySQL]
; Allow or prevent persistent links.
mysql.allow_persistent = Off

Tambien edito el archivo /etc/mysql/my.cnf

Y habilito la siguiente variable:

thread_cache = 16

Con esto ya no me siguio dando el error ya que no deja conexiones persistentes abiertas.