Buenas noches,
Tengo un amigo el cual tiene una empresa en la que tienen un servidor con Windows 2003 y un software de gestión de clientes que tiene una BD de SQL, tiene una política de Backup diario e incremental la cual se ejecuta diariamente.
El disco en el cual está la BD es otro diferente al S.O. (pongamos por ejemplo para definir bien el escenario la unidad D:) , dicha unidad tenía errores de escritura y lectura (supongo que del sistema de archivos, entiendo que "Formateándolo" se recuperaría dicho disco) por lo que el informático que lleva la aplicación se conectó desde Madrid por TS (terminal server) y comprobó que el tamaño de la BD era de 0 bytes e hizo lo lógico, (tirar de backup) pero misteriosamente en el backup NO existía dicho archivo debido a vandalismo (fue "sacado" del backup de forma intencionada por una persona de la empresa a la cual tienen localizada y ha reconocido haberlo hecho, pero eso es agua de otro costal y aunque castigasen a dicha persona de la peor de las formas no se solucionaría el problema que es recuperar esa BD que contiene todos los clientes)...
Tirando de Backups se econtró la bd de hace 6 meses, la cual se llamaba de la misma forma que la que estaba en el programa, llamémosla BD.SQL. El informático vio que la BD del backup se llamaba igual que la "original" y decidió "renombrar" la que está en el disco (recordemos, 0 bytes) de la forma BD.SQL -> BD.SQL1 , recordemos que renombrar es copiar y borrar o mover (como Unix/Linux hace el comando 'mv') por lo que quedó el archivo del Backup (bd.sql) en el sitio del "original" para ser posteriormente borrado.
-Dicho informático (entiendo yo) que la "ha liado parda" ... pero sigo con el viacrucis-
Usó un software de Ontrack (desconozco que versión) el cual SOLO encuentra la versión del backup (el bd.sql que pisó) y no hay forma de recuperar el "original".
Se personó un informático "local" (el problema sucede en Vigo , Pontevedra, el informático que "renombró" se conectó desde Madrid), dicho informático pasó varias utilidades de recuperación basándose en el patrón de software que se utiliza para dichos "menesteres" encontrando siempre el archivo "nuevo" (el del backup)
Concluyo:
Ese archivo es vital para la empresa que no está precisamente es sus mejores momentos (como tantas otras), es la BD de clientes entiendo que la responsabilidad de no hacer un control exhaustivo de los sistemas de backup y de prevenir vandalismo, etc. es directamente de la gente que ahora se lamenta por la carencia del archivo y pido:
Alguna ayuda de cualquier tipo, lógicamente pagando lo que corresponda, dado que yo entiendo que es imposible recuperar dicha BD puesto que la del "backup" está en el sitio de la original.
No se si me he enredado o si me he explicado mal y si será posible recuperar dicho "archivo"
Un saludo y gracias de antemano.
Tema solucionado.
RToucedo27 Febrero 2012 - 11:37am
Buenos días, antes de nada pedír perdon por tardar tanto en contestar.
Al final ha sido viable la recuperación de los datos y ha supuesto unos 5000 € la misma ...
He de "actualizar" algunos matices que creo no haber explicado (dado que los desconocía).
-El archivo en cuestión fue renombrado y en su lugar se puso uno obsoleto. (por lo cual al ser idéntico nombre se "escribió" en el mismo sítio que el anterior y por ello se dio por perdido)
-Existía una copia que carecía del arhico en cuestión (tenía una copia de Junio de 2011) ¿sabotaje ;-O)
-El servidor tenía un RAID-1 el cual supongo ha sido el motivo de la exitosa recuperación.
gracias a todos por vuestra ayuda.
salud!
Por Experiencia
Os23 Diciembre 2011 - 1:09am
Hola --- Para todo hay una primera ves y esta es la mia haciendo un comentario---
Tengo muchos clientes a los que llamamos Manzanos (manasas lo tocan todo... y mas) que no entienden que sus datos son importantes hasta que los pierden , mis recomendaciones por experiencia que te llaman y dicen esto no va y el programa esta alli dentro (toda la informacion que te entrega el atento cliento), todo acompañado de que las copias de seguridad son como las armas de destruccion masiva de irak un gran misterio
Discos duros , lo primero antes de meter datos en uno actualiza su firmware para que vaya mejor. si ya estaba dañado y te entregaba ese error utiliza alguna herramienta de la casa para repararlo ( funcionamiento basico busca los errores y pasa la info contenida en el cluster a otro bueno ) , recomiendo antes de eso crear clonado de disco de sector a sector (Clonezilla buen programa para ello)
Como algun comentario que habia alli "Si vas sobrado de pasta has un raid 5 o algo..." NO considera que si vas a cuidar de esa informacion es una obligacion que tengas mas de una disco para un raid Ej tu servidor sin targeta de red no puede otorgar los servicios pues sin varios discos duros no puede asegurar un funcionamiento optimo sobre la integridad de la informacion es importante que tu lo tengas claro .
Si ahora tienes un servidor dedicado para hacer las copias de seguridad te recomiendo que utilizes linux asi tienes la misma informacion en dos tipos de formatos de tus discos duros distintos Ej NTFS y EXT3 , EXT4 .. etc tienes las ventajas y desventajas que te ofrecen ambos sistemas.
Pasando al recuperado :
Existen programas como GetBackData que optienen resultados muy buenos cuando la informacion a sido sobre escrita , he recuperado sistamas formateados con los datos volcados y he podido recuperar un % considerable, ademas la mejor opcion que hay es aquello una empresa especializada tienen herramientas muy buenas , pero caras ,valora tu informacion con lo que pagaras si lo recuperan o solo por mirar el disco seguro que pordrias haber comprado mas discos y hacer un raid en condiciones incluso poner una maquina palera que te haga de NAS para hacer las copias de seguridad.
Intenta hacer las copias a pelo es decir no utilzes un programa que te haga copias de seguridad (propietario ) y que te cree un solo archivo porque si casca una parte del mismo tienes muchas opciones de perderlo todo encambio si tu programa o BD consta de mas ficheros es mejor que los copias por ti mismo o utiliza un programa de sincronizacion.
Espero que te sea util y que hayas podido solucionar el problema , no es tan caro crear soluciones sobre el resguardo de la informacion si tienes imaginacion ( tambien conociemto ayuda mucho jajajja)
PD: no hay que ser de madrid ni tener un titulo universitario para ser un buen informatico porque esto no te le enseñan en la Universidad en cambio a mi si que me lo ensañaron en un FP , realizando practicas de perdida de datos o caidas de servidores.
Muy buen sitio gracias por existir valoramos el esfuerzo de quienes la manteneis
Actualización.
RToucedo22 Diciembre 2011 - 2:28pm
Ayer he ido por la empresa y me encuentro con un RAID1 y el visor de sucesos no ha vuelto a dar errores de disco...
He usado ZAR (gracias a un post de aquí) pero no me ha encontrado el archivo en cuestion (busco un archivo ANTERIOR a una fecha...) me encuentra el que pusieron de la copia de seguridad (que recuerdo era de JUNIO).
Hoy iré de nuevo con el clonezilla a colnar el RAID en un disco nuevo y así mandar el RAID a la empresa de recuperacion que el cliente solo quiere mandarlo allí sin ninguna garantia de exito (es cabezón e informaticamente hablando muy ignorante y esa mezcla es peligrosa) pero al fin y al cabo el problema es de él.
Como os comentaba en el primer post, hay un archivo .MDF (que está bien y es la base de datos primaria) y DOS .NDF con un tamaño de 0 (son bases secundarias por lo que tengo entendido, el .MDF desborda en ellas ¿? que es el famoso archivo que falta.
2011V1_dat.ndf
2011V1_ldx.ndf <- no se si es idx
estos dos archivos están con una copia de junio y los datos de aquel entonces
2011V1_dat.ndf-
2011V1_ldx.ndf-
estos dos (con la rallita al final) están a 0 b.
y la base de datos "principal" .mdf está bien pero el día que se renombró los otros dos también se renombró la misma
2011V1.mdf (en "produccion")
2011V1.mdf- (la "copia")
gracias de nuevo
Anda dime...
Inspector de datos19 Diciembre 2011 - 4:24pm
Anda, dime ¿que empresa es?, que se ha ganado un bonito expediente por falta de medidas de seguridad. (es broma, pero ¿a que acojona?)
¡Se han cometido todos los errores que se podían cometer! ¿pero que clase de profesionales tienen contratados? Las políticas de seguridad, las políticas de respaldo y recuperación, los planes de continuidad de negocio y recuperación de desastres no se hacen porque a los que nos dediquemos a esto nos guste escribir, que no nos gusta, sino ¡porque hacen falta! porque siempre hay algún manazas que va y la fastidia.
Ahora comprenderéis porque las sanciones de la AEPD son lo de menos a la hora de cumplir con las medidas de seguridad. Como la fastidies bien estas pero que bien fastidiado.
La empresa tiene toda la
RToucedo21 Diciembre 2011 - 5:18pm
La empresa tiene toda la "info" en PAPEL... (glorioso papel...) que si no hubiese cerrado IPSO FACTO dado que no saben a quién cobrar por lo que no podrían ni pagar nóminas.. impuestos...
Hoy ha llegado el disco SAS para clonar el "dañado" sobre él y voy a echarle una mano.
Intentaré usar los programas que me habéis recomendado pero intuyo dada la "gañanéz" que ha desmostrado esta gente que estarán usando dicho disco ....
seguiremos informando y gracias de nuevo por los consejos / explicaciones.
Gracias
RToucedo19 Diciembre 2011 - 9:42am
Gracias a todos por vuestras respuestas, se han puesto en contacto con una multinacional de recuperación de datos (no digo el nombre por no publicitar) de todas formas espero que esta gente pueda recuperar (aunque sea codificando información en papel) y que gracias a esto tanto ellos como otras personas que lean estas lineas se conciencien de una santa vez la importancia de hacer copias de seguirdad...
Lo que yo haría
m17 Diciembre 2011 - 1:23am
El intentarlo con herramientas de recuperación sobre un clonado del disco sería la primera opción. Pero a estas alturas imagino que ya lo habréis probado.
Hasta donde tengo entendido, o lo que el ejercito estadounidense hace para borrar con seguridad un archivo es sobreescribir con ceros y unos un número veces (si mal no recuerdo 4) para que sea irrecuperable. Si lo hacen 4 y no 3, por poner un ejemplo (tengo por seguro que eran más de dos iteraciones), es por algo. En último caso contactaría con profesionales de recuperación de datos, el único problema es que sí la empresa no va muy holgada seguramente salga en un pico que os complique un poco más la vida.
Hola, lo que he leido es que
RToucedo19 Diciembre 2011 - 9:38am
Hola, lo que he leido es que con una sola pasada ya no hay forma...
GetDataBack
xavitxus201116 Diciembre 2011 - 10:46pm
Prueba ese software, a mi me funciona bastante, es capaz de detectarte varias versiones de un fichero borrado/formateado dependiendo de que MFT selecciones, a lo mejor tienes suerte. Por supuesto te recomiendo las anteriores recomendaciones que te han hecho a la hora de salvaguardar un original de la informacion del disco y demas.
http://www.runtime.org/data-recovery-software.htm
Hay un problema adicional...
jonsito16 Diciembre 2011 - 10:22pm
Estamos hablando de un fichero de base de datos... En este caso, dependiendo de la base de datos y de la configuración, la estructura de datos _dentro_ del fichero, puede corresponder desde un simple texto csv, a un fichero binario de estructura y contenido poco menos que aleatorio.... y si encima los datos están cifrados...
Ignoro qué podrían hacer los programas de rastreo del contenido de un disco con este tipo de ficheros. Yo he recuperado fácilmente (cientos de) ficheros jpeg de una tarjeta de memoria corrompida de una cámara de fotos, pero no tengo muy claro que dichos programas funcionen bien con un único fichero de varios cientos de gigas... salvo que sepas _a_priori_ la estructura del fichero de base de datos y utilices un programa específico para dicho tipo de datos
Como te dicen por ahí, posiblemente tengáis que acudir a un profesional... y revisar la política de backups
Los backups
tulipon16 Diciembre 2011 - 4:23pm
hay que probarlos regularmente para asegurarte de que se hicieron bien, son funcionales y el proceso de "vuelta a tras" funciona, pero claro el becario a todo no llega y luego pasan estas cosas, aunque algo asi es de esperar de una empresa que te pone la bbdd de todos tus clientes a correr sobre software de microshit.
¿Informatico?
Broderick16 Diciembre 2011 - 1:52pm
Y el famoso "informatico" de Madrid cobrara 20000€/año, y yo aqui en el puto paro sabiendo lo que habia que hacer desde el principio.
No hay justicia, eso si, como me decia un amigo informatico (pero de los de verdad): "menos mal que existe Windows y el NTFS para que podamos comer"
¡Uy lo que ha dicho!
Calario16 Diciembre 2011 - 3:01pm
(malo malo a lavarse la boca)
Todo lo que he leído esta muy bien, pero yo apagaría el equipo y llamaría a una empresa que se dedique a esto, porque los profesionales de la materia saben que sobreescribir sobre un fichero no garantiza su borrado físico, sobre todo si se machaca todo con el mismo valor.
no problemo
pulidlc16 Diciembre 2011 - 12:51pm
Por partes:
1.- el renombrar del fichero en windows,solo cambia una entrada de la DIR,la cadena de clusters que definen el fichero no se ha modificado.
2.- Como el fichero media 0 bytes,la cadena de clusters que definen el fichero esta perdido, y por tanto tampoco se puede volver a estropear (eto es bueno,pq podria sobreescribirse y entonces sí que la liamos)
3.- Para poder recuperar ese fichero has de utilizar un programa que lee los sectores uno por uno buscando patrones de cabecera de ficheros y los encadena, reescribiéndolos en otro medio (quizas un disco USB externo).
POR EJEMPLO: URGENT RECOVERY PRO
4.- La probabilidad de éxito es directamente proporcional a:
4.1 - que el disco no está fragmentado
4.2 - la base de datos no crezca dinámicamente (osea, que siempre mide lo mismo pq ha sido redimensionada de antemano para evitar justo estas fragmentacion
Mucha suerte
Exacto
inar16 Diciembre 2011 - 2:57pm
Renombrar no copia ni mueve datos. Por tanto, la información debiera estar en los mismos clústeres originales.
Tan solo un matiz o ampliación a tu punto 2:
El problema es que si el archivo marca tamaño 0, para la FAT del disco esos clústeres aparecerán como disponibles para escritura y hay riesgo que puedan ser utilizados, y con ello machacada la información del archivo.
Por ello es MUY IMPORTANTE lo que comentan más arriba de apagar el equipo tirando literalmente del cable, a fin de evitar incluso que el propio sistema pudiera utilizar alguno de esos clústeres durante el proceso de apagado.
Seguidamente, recomendable extraer la unidad y tratarla como medio externo desde otro equipo. Si no es posible, hacerlo localmente iniciando equipo con algún CD Live de otro S.O. o herramienta de recuperación.
En todos los casos, SIEMPRE, hacer un clonado binario del disco como respaldo. En caso que durante el proceso de clonado dé errores (por problemas físicos de la unidad), configurar el programa de clonado para que ignore errores, y hacer dos clonados en unidades distintas, a fin de hacer inicialmente pruebas de recuperación sobre una de las copias, y asi no tocar el original salvo que sea extrictamente necesario.
Y si...?
Revenarius16 Diciembre 2011 - 12:51pm
...admitimos que el disco principal se ha "perdido" y tratamos de recuperar la copia de la BD. Según entiendo el escenario es el mismo, salvo que no se ha copiado nada por encima. De todas formas la copia incremental...¿sólo una copia completa cada 6 meses? yo investigaría si existe una copia completa "en algún sitio".
Mala solucion tiene
jorgegv16 Diciembre 2011 - 12:17pm
De entrada aviso de que en este comentario no vas a encontrar una solución porque los datos probablemente (si he entendido correctamente tu post) han sido sobreescritos con los del backup de hace 6 meses y no teneis copia de seguridad. Yo creo que conviene empezar a asumir el escenario de desastre total.
Pero hay varias cosas que me vienen a la cabeza (para mejorar en el futuro):
Dices que con un disco que da errores de lectura y escritura se puede recuperar reformateandolo. Gran error. Un disco que falla hay que cambiarlo inmediatamente. Los discos duros magneticos tienen una vida util de aproximadamente unos 5 años, y además son inteligentes: cuando un sector de un disco da errores de lectura o escritura, el propio hardware del disco remapea ese sector defectuoso a otro disponible, para lo cual un disco reserva un porcentaje de su capacidad bruta (es decir, que un disco de 100 GB pude tener por ejemplo 10 GB de reserva para estos remapeos. Y esta capacidad no está disponible para el usuario).
Es decir, que cuando un disco te avisa de que está dando errores, no significa que "está empezando" a dar errores, significa que lleva dando errores un tiempo y se le ha acabado el espacio de reserva para remapear sectores defectuosos. Por eso es tan importante tener los discos con algún tipo de redundancia RAID.
Entiendo que al menos tenéis la copia de la BD de hace 6 meses, con lo que solo habríais perdido los datos de los últimos 6 meses.
Y me pregunto cómo es posible que un usuario que no es el administrador del sistema tenga acceso a una configuración del backup de la empresa. Y si ha sido el administrador, entonces seguramente la empresa pueda denunciarlo y obtener una indemnización de él por los 6 meses de trabajo perdido. Quiza al cabo de años de juicios.
Las enseñanzas que yo sacaría de este incidente:
Muchas de estos temas hoy día se pueden hacer con muy poco esfuerzo e inversion dados los precios del almacenamiento de hoy en día (vale, justo los de ahora no, con las inundaciones de Tailandia).
De entrada aviso de que en
RToucedo19 Diciembre 2011 - 9:37am
Ya lo he asumido, el problema me gustaría dejar claro que no es mío si no de un "amigo" que me llamó " a voz "postuma".
El disco si falla falla, ya lo he entendido :) y no se debe reutilizar.
La culpa no es de ese "usuario" mal intencionado o no si no del responsable de la empresa, el "usuario" era el "responsable" de que se hiciese el "backup" y sus conocimientos se basaban en ver que había "fechas nuevas", cabe destacar que el "usuario" era un administrativo que le calló "el gordo" de hacer dichas copias.
Empezó a fallar el día 13/12 y ya no hubo nada que hacer.
Lo se y lo recomendé siempre, pero me "avisaron" " aver si podia hacer algo"...
Se va a hacer un raid1, backup contra disco externo y copia en servidor dedicado (externo) que va a adquirir.
Ya, pero no es el primer "marron" que veo que pasa por algo similar, yo creo que mucha gente sigue sin tener conciencia de la importancia de tener su informacion respaldada, lo que no entiendo que si tan importante es la información (el archivo que se perdió es el que contiene los clientes por lo que ni la declaración de la renta podrían hacer dado que las facturas, en el campo de clientes se asocian a "nadie", no podrían pagar nóminas dado que no pueden facturar (por que no saben a quien) y muchas mas animaladas...
Por suerte para ellos tienen todo en "papel" y ha aparecido un archivo que contiene a los deudores...
muchísimas gracias por contestar.
Cómo se hizo el backup
rmonclus16 Diciembre 2011 - 11:41am
Mi pregunta es:
¿De qué servidor de BBDD estamos hablando?
¿Cómo se hizo el Backup? Se trata de un backup de BBDD a fichero y lo que copiamos es el fichero o se trata de una copia del fichero de datos de la BBDD (mala idea)
Si lo que tenemos es el fichero de datos de la BBDD ¿tenemos también fichero de transacciones?
Pues nada que para poder ayudaros creo que falta información.
Mal asunto
zoom_one16 Diciembre 2011 - 9:52am
Desde mi punto de vista, el hecho de de renombrar la base de datos no ha sido la cagada (al margen del tema de backups, se entiende). Después de todo, sólo se modifican datos en la tabla de asignación de archivos. Incluso, si se hubiera hecho un borrado "normal" del archivo, se hubiera podido encontrar algún rastro del mismo con algún soft de recuperación. La razón es que los datos del disco no se eliminan, sino que se marcan los bloques como libres para escribir en ellos. El problema viene cuando se siguen escribiendo datos en disco (recuperación de la copia, en este caso). Lo que haría yo, para empezar, es sacar el disco inmediatamente del servidor, hacer un par de imágenes raw (comando dd de linux, por ejemplo) y trabajar con ellas con distintos programas de recuperación. Sinceramente, parece que lo tenéis crudo. Suerte.
A bote pronto
squirrel16 Diciembre 2011 - 9:30am
1) Apagado inmediato de la máquina.
2) Clonado del disco.
3) Copia del clon a lugar seguro, por si hiciera falta volver a empezar el proceso de recuperación varias veces.
4) Utilizar utilidades específicas de recuperación de archivos borrados en base a las "cadenas" de sectores que quedan al borrar (realmente al borrar un archivo éste no desaparece del disco, sólo se borra su entrada en la tabla de inodos correspondiente y sus sectores pasan a la lista de sectores disponibles).
Para utilidades de ese tipo tienes varias para diferentes SSOO y con diferentes funcionalidades, basta con una búsqueda por Internet. Yo he probado satisfactoriamente el ZAR (Zero Assumption Recovery), que es de pago (aunque no caro) pero hay otros, incluido software libre.
En el peor de los casos, hay empresas especializadas en este tipo de trabajos. No son especialmente baratas, pero ahí ya entra el valor real de lo perdido.
Por cierto, la destrucción intencionada de material de la empresa es delito, o al menos eso tengo entendido. Más aún cuando la persona lo hace conociendo perfectamente el perjuicio que causa dicha acción.
Suerte.
Tal vez...
Rizobix16 Diciembre 2011 - 8:45am
Si la base de datos ocupa menos de la mitad del disco duro, a lo mejor hay suerte y los datos no se han perdido, puesto que, tal vez, la base de datos restaurada se haya escrito sobre la parte libre del disco.
Yo, en cualquier caso, compararía dos disco nuevos de igual o mayor capacidad al que tiene la base de datos.
El primero, porque desconfío de un disco que ha dadao probelmas, lo usaría para sustituir el antiguo.
El segundo, lo usaría para sacar una copia física del disco malo, para poder enredar sobre ella sin poner en peligro más los datos.
Primero: con el disco 'segundo' y el original conectado, en una máquina que ejecute alguna variante de GNU/Linux (puede ser desde un pendrive), haría la copia del disco original en el 'segundo'. Hay que utilizar el comando 'dd'.
Segundo: con el disco 'segundo' y el 'primero', haría una copia usable, también con el comando 'dd', y esa es la que dejaría puesta para que el trabajo continúe en la empresa, aunque sea con la base de datos de hace 6 meses, mejor eso que nada.
Tercero: En otro ordenador, y utilizando todo el timepo que sea necesario, en una máquina con GNU/Linux conectaría el disco 'segundo' y me dedicaría:
a) A buscar si en la FAT o equivalente se puede identificar una cadena larga de sectores conectados entre sí pero sin entrada válida en directorio, y le crearía la entrada. Eso es lo que hacen los programas de 'delete recovery'. Si funciona, pues ya está.
b) La cadena existe, pero no está completa. Habría que ver si se puede restaurar mínimamente la base de datos para recuperar todos los posibles. Eso depende del tipo de base de datos.
c) Si la cadena no existe. Armarse de paciecia, y con un editor hexadecimal adecuado, buscar por toso los sectores del disco las cadenas significativas de las bases de datos (¿nombre? ¿dirección?) y una vez localizadas las que no pertenezcan a la base restaurada, tratar de recuperar los datos. Eso, también depende de la base de datos en concreto.
Suerte, y ¡al toro!
Estas frito
Carlos.ornella16 Diciembre 2011 - 5:16am
No hay manera de recuperar NADA, si el tecnico piso el archivo...adios recuperacion posible
Se puede ser tan PAPAFRITA De recuperar un archivo de un backup no viendo que pesaba cero?
Toca agarra todas las facturas de venta, y cargar los clientes uno por uno
Vaya...
Deiwor16 Diciembre 2011 - 3:04am
Vaya, pensaba que era un post como tantos otros donde explicáis maravillas, pero es una petición. Voy a intentar explicar hasta el punto que yo se de recuperación, pero teniendo en cuenta que son las 2am, si meto la pata que me corrija alguien por favor.
En primer lugar, ante una pérdida de información, hay que utilizar ese dispositivo lo menos posible como elemento principal, ya que como todos sabemos, que el fichero esté eliminado no implica que haya desaparecido siempre y cuando no se haya sobrescrito nada en esos sectores.
Si partimos de la base de que el que ha hecho el vandalismo NO ha sobrescrito el disco duro con 0000000000...000 (Wipearlo), que alguien haya cambia el nombre de la BBDD de un nombre u otro no debería afectar mientras no se haya escrito en esos sectores anteriores. (Esto se cumple con FAT/FAT32, ahora mismo dudo si NTFS es igual, aunque el comportamiento básico si que es similar).
Es un trabajo tedioso, pero si tenéis una BD de hace 6 meses, yo probaría a volcar la imagen completa del disco duro (para evitar que se dañe más información), ver cómo son las cabeceras del fichero de hace 6 meses (ya que las cabeceras deben ser similares de las actuales a las de antaño), y buscarlas sobre el volcado, pero búsquedas de fragmentos.
El problema es, que cuanto más grande haya sido el fichero, más probable es que esas regiones de memoria hayan sido utilizadas por el sistema de forma temporal y haya dejado datos corruptos. Es un trabajo de chinos, pero aunque no se pueda recuperar todo el fichero, se pueden recuperar partes del mismo
Espero haberme podido explicar bien...
Y el backup donde estaba?
clean7516 Diciembre 2011 - 2:50am
Obviando el disco original, que está bastante trasteado...
Las copias de seguridad ¿en que soporte estaban? ¿se ha utilizado este soporte despues del borrado malintencionado?
Recuperación Datos
security4dev16 Diciembre 2011 - 2:50am
Hola ¿Rafael :) ? ... yo lo que haría en primer lugar y antes de nada es: NO TOCAR EL EQUIPO, o por lo menos más de lo que se tocó, puesto que se puede alterar (más de lo necesario :(
A continuación lo que yo haría sería:
1º Apagar el equipo (dándole un tirón al cable de alimentación, es decir, apagando dándole al interruptor de encendido/apagado en la fuente, no desde el sistema operativo).
2º Crear una copia exacta (a nivel de bit) del disco, una forma sería utilizando alguna distribución de análisis forense en formato LIVE CD, como CAINE/DEFT. Esta copia podemos almacenarla en un disco usb externo. Ten en cuenta que si el disco (del equipo afectado) es de 500GB, pués la copia ocupará 500GB aunque tuvieses espacio libre, puesto que es una copia BIT A BIT.
3º Ahora sí que se podría intentar recuperar los archivos de base de datos con tranquilidad utilizando software avanzado de recuperación de archivos. (y evidentemente sobre la copia realizada y montada como SOLO LECTURA, por seas caso)
Espero que esto te pueda servir y que alguien aporte algo más útil.
Un Saludo.
Obviando la poca posibilidad
clean7516 Diciembre 2011 - 2:48am
Obviando la poca posibilidad de recuperación del disco original habiendo escrito datos encima y haciendo sabe dios que más... me pregunto el backup ¿en que soporte estaba? ¿disco?
¿Se ha escrito algo en el soporte de backup del que se ha borrado la copia, después de ese intento de recuperación?