Recuperación de datos en la nube: Microsoft 365 y Google Workspace en Panamá

¿Qué es la recuperación de datos en la nube?

Cuando una empresa pierde un buzón, una biblioteca de SharePoint o una carpeta de Google Drive, el problema no se parece en nada al de un disco averiado. No hay nada que abrir ni reparar: la información vive en los servidores de Microsoft o Google, y recuperarla depende de las herramientas que esas plataformas ofrecen, de los plazos en que lo permiten y de si la empresa tenía un respaldo independiente. La recuperación en la nube es, por eso, una disciplina distinta: una carrera contra las ventanas de retención, combinada con el uso experto de las opciones de administración y, cuando toca, con la exportación forense de la evidencia.

Conviene decirlo con franqueza desde el inicio: esto no es «hackear» una cuenta. Trabajamos siempre por las vías legítimas —la consola de administración, las herramientas nativas, el respaldo de la propia organización— y con la autorización del titular de los datos. Lo que aportamos es saber exactamente qué se puede recuperar, por dónde y en cuánto tiempo, antes de que la ventana se cierre.

Esa distinción también define quién puede ayudar. Recuperar un disco exige un laboratorio y herramientas físicas; recuperar la nube exige conocer a fondo las consolas de administración, las ventanas de cada servicio y las reglas de eDiscovery de cada plataforma. Son dos especialidades distintas, y confundirlas hace perder un tiempo que, en la nube, casi nunca sobra.

¿Microsoft y Google respaldan mis datos?

No de la forma en que casi todo el mundo asume. Ambos operan bajo el llamado modelo de responsabilidad compartida: la plataforma responde por la infraestructura —que el servicio esté disponible, que no se caiga el centro de datos—, pero el cliente es responsable de respaldar y recuperar sus propios datos. Microsoft lo dice de forma explícita en su acuerdo de servicio, donde recomienda respaldar con regularidad el contenido que guardas en el servicio. Google lo plantea igual en su documentación.

La confusión más cara nace de creer que la replicación equivale a respaldo. No lo es: Microsoft y Google replican tus datos para protegerse de un fallo de hardware suyo, no para recuperarte de un borrado, un ataque o un empleado que vacía su OneDrive al irse. Y un detalle clave: lo que se replica borrado o cifrado se replica igual de borrado o cifrado. La copia que te salva de un ransomware no es la que vive dentro de la misma plataforma comprometida.

¿Por qué se pierden datos en la nube?

Los escenarios se repiten en casi todas las empresas, y rara vez tienen que ver con un fallo técnico de la plataforma:

• Borrado accidental o malicioso. Un usuario elimina por error una carpeta compartida, o alguien lo hace a propósito antes de marcharse.
• Salida de empleados. Al dar de baja una cuenta, su buzón y sus archivos quedan sujetos a ventanas de retención que vencen rápido si nadie actúa.
• Ransomware sincronizado. El cifrado de un equipo se propaga a OneDrive, SharePoint o Drive, y los atacantes suelen vaciar las papeleras al entrar para cerrar la recuperación nativa.
• Políticas de retención mal configuradas. Una regla mal puesta puede purgar datos que nadie quería borrar.
• Cuentas de administrador comprometidas. Si se altera o borra desde un acceso privilegiado, la reconstrucción puede exigir un respaldo de terceros.
• Cargas de trabajo olvidadas. Teams y las cuentas de directorio (Entra ID) están entre lo menos respaldado, y Microsoft no los respalda por ti.

Lo que tienen en común casi todos estos escenarios es que la plataforma funcionó a la perfección: nada se cayó, nada falló del lado de Microsoft o Google. Los datos se perdieron por una acción —humana o maliciosa— sobre un servicio que hizo exactamente lo que se le pidió. Esa es, justamente, la mitad de la ecuación que le toca cubrir al cliente.

Microsoft 365: qué se puede recuperar y hasta cuándo

Microsoft 365 ofrece varias funciones de recuperación, pero todas tienen plazos y límites que conviene conocer antes de necesitarlas:

El matiz importante: el bloqueo por litigio y las políticas de retención sirven para cumplimiento, no para restaurar. Conservan los datos en su sitio y están pensados para exportar (eDiscovery), pero no devuelven un buzón a como estaba en una fecha concreta. Pasado el plazo de la papelera, o si una política los purgó, los datos pueden quedar fuera del alcance nativo.

Conviene añadir dos puntos recientes. Microsoft lanzó su propia función de respaldo (Microsoft 365 Backup), pero en 2026 cubre solo una parte de las cargas —SharePoint y OneDrive— y con límites de retención y granularidad frente a una solución de terceros. Y la llegada de Copilot y los agentes de IA suma nuevos accesos a los datos que el modelo de responsabilidad compartida tradicional no contemplaba, otra razón para no dejar la protección al azar.

Google Workspace: qué se puede recuperar y hasta cuándo

Google Workspace funciona con una lógica parecida, con plazos algo más cortos y una restauración de administrador poco granular:

Sumando la Papelera y la restauración de administrador, Google da un máximo de 55 días desde el borrado. Después, los datos se purgan y Google no los recupera, ni siquiera por soporte técnico. Vault ayuda solo si había una regla de retención configurada antes del incidente; si la papelera se vació y no había regla, lo borrado deja de estar disponible para Vault.

Hay un matiz más que sorprende a muchas empresas: la restauración de administrador de Google no es granular. Recupera todo lo borrado en un rango de fechas, sin poder elegir archivos sueltos, lo que puede devolver al usuario un montón de material no deseado. Y Google Takeout, la exportación de datos, no es una función de restauración: sirve para descargar, no para devolver las cosas a su sitio.

¿Y si ya pasó la ventana de retención?

Aquí está la respuesta más honesta y, a menudo, la más difícil de dar: si la ventana nativa venció y no existe un respaldo independiente, lo más probable es que los datos ya no se puedan recuperar. No hay un laboratorio que «abra la nube» como se abre un disco; lo que Microsoft o Google purgan tras sus plazos deja de existir en sus sistemas. Por eso, en la nube, la velocidad de reacción no es un detalle: es casi todo.

Lo que sí podemos hacer, incluso en esos casos, es agotar cada vía disponible —papeleras secundarias, versiones, retenciones que sigan activas, respaldos que la empresa no sabía que tenía— y documentar con claridad qué se recuperó y qué no. Y si había un respaldo de terceros, por incompleto que parezca, lo aprovechamos al máximo. Preferimos decir la verdad sobre lo que es recuperable antes que vender una esperanza que no se sostiene.

Ransomware en la nube

El ransomware ya no se queda en los servidores físicos. Cuando cifra los archivos de un equipo sincronizado, esos cambios suben a OneDrive, SharePoint o Drive, y la versión cifrada reemplaza a la buena. Algunas funciones ayudan —la restauración de archivos de OneDrive permite volver a un punto de los últimos 30 días, y el historial de versiones de SharePoint puede revertir cambios—, pero los atacantes más cuidadosos vacían las papeleras y agotan las versiones precisamente para cerrar esas salidas. Aquí el trabajo se cruza con la recuperación ante ransomware: contener, preservar y restaurar desde la copia que el ataque no pudo tocar.

La lección operativa es doble: cortar la sincronización en cuanto se detecta el cifrado, para que no suban más versiones dañadas, y no confiar en que la papelera de la nube guarde la versión buena, porque suele ser lo primero que el atacante vacía.

Preservación forense de evidencia en la nube

No toda recuperación en la nube termina en restaurar: a veces lo que importa es preservar. En una disputa laboral, un fraude o una fuga de información, los correos y archivos de la nube son prueba, y deben extraerse sin alterarlos y con su cadena de custodia intacta. Para eso usamos las herramientas de eDiscovery y los bloqueos legales de cada plataforma, exportando la evidencia de forma defendible. Ese trabajo se apoya en nuestro peritaje informático forense bajo ISO/IEC 27037, de modo que lo recuperado de Microsoft 365 o Google Workspace pueda sostenerse ante un tribunal.

Esa preservación tiene su propio reloj: si no se aplica un bloqueo legal a tiempo, las mismas ventanas de retención que borran un archivo cualquiera pueden eliminar la prueba. Por eso, ante un litigio en el horizonte, asegurar la evidencia es de lo primero que hay que hacer.

Cómo trabajamos un caso en la nube

El primer movimiento siempre es medir cuánto tiempo queda, porque define todo lo demás. A partir de ahí, el método combina vías nativas, respaldo y, si hace falta, preservación forense.

1. Triaje urgente

Determinamos qué se perdió, cuándo y en qué servicio, para saber cuánto margen queda antes de que venza la retención. En la nube, cada día cuenta.

2. Vías nativas y de administración

Recuperamos lo posible desde papeleras, versiones, retenciones activas y la consola de administración, con la autorización del titular.

3. Restauración desde respaldo

Si la organización tiene respaldo de terceros, lo aprovechamos para una restauración granular y a un punto concreto en el tiempo.

4. Exportación forense

Cuando hay litigio, exportamos la evidencia con eDiscovery y cadena de custodia, lista para sostenerse en un proceso.

5. Plan de respaldo

Dejamos una recomendación honesta para que el próximo incidente no dependa de unas ventanas de días.

# Buscar elementos recuperables de un buzón (vía legítima de administración)
PS> Get-RecoverableItems -Identity [email protected] `
       -FilterStartTime "01/05/2026 00:00" -FilterEndTime "31/05/2026 23:59" `
       -SourceFolder DeletedItems
... 1.284 elementos recuperables

# Restaurar a la carpeta original
PS> Restore-RecoverableItems -Identity [email protected] -FilterItemType IPM.Note
# Si la ventana ya venció y no hay respaldo de terceros, esta vía se cierra.

Ese comando solo funciona dentro del plazo de retención y con permisos de administración legítimos. Es la diferencia entre actuar a tiempo y descubrir, demasiado tarde, que el correo ya fue purgado de forma definitiva.

¿Pueden recuperar la cuenta de un empleado que se fue?

Depende de cuánto haya pasado. En Microsoft 365 y en Google Workspace, dar de baja a un usuario activa ventanas de recuperación —en Google, por ejemplo, una cuenta borrada se restaura dentro de los 20 días— pero esos plazos corren rápido. Si el offboarding incluyó vaciar el buzón o la unidad, el reloj se acorta todavía más. Por eso recomendamos a las empresas no eliminar de inmediato las cuentas de quienes salen, sino convertirlas en buzones compartidos o conservarlas el tiempo que exija la normativa. Cuando nos llaman a tiempo, recuperamos; cuando ya venció todo y no había respaldo, lo decimos con claridad.

Cómo evitar la próxima pérdida

La conclusión de casi todos estos casos es la misma: las ventanas nativas no son un plan de respaldo, y conviene tratarlas como lo que son, una última red de seguridad de pocos días. La forma de no depender de ellas es un respaldo de terceros para Microsoft 365 o Google Workspace que copie correo, archivos, sitios, Teams y cuentas de directorio fuera de la propia plataforma, con restauración granular y a un punto concreto en el tiempo: poder recuperar un solo archivo o un solo buzón sin arrastrar todo lo demás.

A ese respaldo conviene sumarle dos hábitos baratos y decisivos. El primero, probar de verdad que las copias se restauran: un respaldo que nunca se ha probado es una suposición, no una garantía. El segundo, ordenar el offboarding y la retención: no borrar de golpe las cuentas de quienes salen, convertirlas en buzones compartidos durante el tiempo que exija la normativa y revisar que ninguna política esté purgando lo que no debe. En el cierre de cada caso dejamos estas recomendaciones por escrito; no vendemos software de respaldo, pero hemos visto demasiadas veces lo que cuesta no tenerlo, y preferimos clientes que no tengan que volver por una urgencia que se pudo evitar por completo con una configuración de respaldo correcta, bien probada y mantenida desde el primer día.

Casos frecuentes en empresas panameñas

Atendemos a empresas que migraron al correo en la nube y asumieron que «Microsoft ya respalda todo», y descubren lo contrario el día del incidente. Vemos buzones de directivos vaciados tras una salida conflictiva, carpetas de SharePoint o Drive borradas por error en plena operación, y casos de ransomware que se propagaron a la nube desde un equipo sincronizado. Trabajamos de la mano del área de TI y, cuando hay un componente legal, con los abogados de la empresa, exportando la evidencia de forma defendible. Coordinamos la atención en toda la república y activamos la línea de emergencia cuando el reloj de retención está por vencer, con el recargo que ese servicio prioritario conlleva.

El patrón de fondo se repite tanto que vale la pena nombrarlo: la mayoría de estos incidentes no son fallos de Microsoft ni de Google, sino decisiones de configuración o de proceso que nadie revisó a tiempo. Cuando una empresa entiende que la nube le da disponibilidad pero no respaldo, deja de improvisar y empieza a protegerse en serio.

Preguntas frecuentes