Estado en vivo, público y sin registro
status.yo-facturo.com publica uptime, incidentes históricos y el estado de los servicios externos de los que dependemos (incluido AFIP/ARCA) — sin necesidad de iniciar sesión.
Disponibilidad y continuidad
Además de proteger tus datos (ver Seguridad), nos comprometemos a que estén disponibles y sean recuperables. Esto es lo que hacemos, en números concretos derivados de nuestra operación real — no proyecciones de marketing.
status.yo-facturo.com publica uptime, incidentes históricos y el estado de los servicios externos de los que dependemos (incluido AFIP/ARCA) — sin necesidad de iniciar sesión.
Cada mes restauramos automáticamente el último backup de MongoDB en un espacio de nombres aislado (nunca sobre datos reales), verificamos la integridad contra un manifiesto de colecciones y lo eliminamos al terminar. El resultado queda auditado.
Los backups nuevos se escriben en un almacenamiento con Object Lock (WORM — Write Once, Read Many): durante la ventana de retención, ni siquiera un atacante con las credenciales de escritura puede modificarlos o borrarlos.
Todo backup se cifra con AES-256 antes de salir de nuestra infraestructura hacia el almacenamiento externo. La clave de cifrado nunca viaja junto a los datos.
El RPO (Recovery Point Objective) es cuántos datos como máximo podrías perder ante una contingencia — se deriva directamente de la frecuencia real con la que respaldamos cada tipo de dato:
| Tipo de dato | Cadencia de backup | RPO objetivo |
|---|---|---|
| MongoDB — facturación, clientes, stock, cuentas corrientes | Backup automático diario (03:00 ART), cifrado AES-256 | Hasta 24 h de datos en el peor caso (ventana entre dos backups diarios) |
| MinIO — comprobantes, imágenes, archivos adjuntos | Backup automático diario (03:45 ART), cifrado AES-256 | Hasta 24 h de datos en el peor caso |
| Vault — secretos, certificados AFIP/ARCA, claves de cifrado | Backup automático diario + inmediatamente después de cada rotación de credenciales | Hasta 24 h en operación normal; minutos alrededor de una rotación (backup post-rotación automático) |
El RTO (Recovery Time Objective) es cuánto tardaríamos en restaurar el servicio ante una contingencia mayor. Hoy es un objetivo operativo interno, no un compromiso contractual: recién se convierte en un número confiable después de acumular varios simulacros de restauración reales y medir la duración efectiva de una restauración completa contra el volumen real de producción. Publicamos la cadencia y el proceso de medición para que sea verificable — si tu empresa necesita un RTO con penalidades contractuales, lo definimos junto a un SLA a medida.
Descargamos el último backup de MongoDB, lo restauramos en bases con un espacio de nombres exclusivo para el simulacro (nunca las bases reales), verificamos los conteos de colecciones contra el manifiesto generado al momento del backup, y eliminamos las bases temporales — incluso si algún paso falla a mitad de camino.
Cada simulacro deja un resultado firmado con fecha, backup utilizado y resultado de la verificación, además de una notificación al equipo de operaciones ante cualquier fallo.
Los backups nuevos (MongoDB, Vault) se escriben en un bucket con Object Lock habilitado desde su creación — una protección que, por diseño de la tecnología subyacente, no puede aplicarse retroactivamente sobre backups históricos. El historial previo al corte permanece disponible en modo solo lectura para restauraciones antiguas.
Los objetivos de esta página son nuestro compromiso operativo estándar, disponible para todos los planes. Para acuerdos de nivel de servicio (SLA) con créditos por incumplimiento, RTO garantizado por contrato, residencia de datos dedicada o requisitos de continuidad específicos de tu industria, mirá latabla de créditos y opciones de residencia Enterprise o armamos una propuesta a medida.
Consultá también Seguridad, nuestra Política de Seguridad, el SLA contractual y residencia de datos y elestado en vivo de la plataforma.