← Todas las funciones

Aporte su propio almacenamiento

Por Lucas Flores, IT Systeme Flores UG. Última actualización: 2026-10-29

Restow escribe los datos de copia de seguridad como bloques deduplicados y cifrados (fragmentación definida por contenido, hashes SHA-256, empaquetados en archivos de paquete) en el almacenamiento que usted elija. El destino por defecto no necesita ningún servicio adicional: disco local en un volumen Docker dentro del mismo contenedor, de modo que Restow se ejecuta de forma totalmente autocontenida, solo con él mismo más PostgreSQL, y ningún dato tiene que salir nunca de su servidor. Apunte en su lugar a almacenamiento de objetos compatible con S3, o un recurso NFS montado, y el almacenamiento es exactamente tan bueno, barato o local geográficamente como lo que usted haya elegido. No hay ningún recargo por encima de ello.

Por qué «aporte el suyo» en lugar de una nube de Restow

Restow no opera ningún servicio de almacenamiento alojado, y no hay ningún plan de hacerlo. Véase, en inglés, Your data is your data para el razonamiento completo. En la práctica, eso significa que su factura de almacenamiento es su factura de almacenamiento: elija un proveedor compatible con S3 económico, reutilice capacidad que ya paga, o mantenga todo en disco local sin nada medido por gigabyte, por restauración ni por llamada a la API. Se admite más de un destino de almacenamiento por organización: un destino principal más una copia es el patrón habitual para mantener una copia de la copia de seguridad.

Repositorios que puede añadir

Donde se guardan las copias se llama repositorio: hay una entrada de menú Repositorios bajo su organización. El propietario de la instalación define el almacenamiento predeterminado (una ruta local o un bucket compatible con S3) en Instalación, Repositorio predeterminado, y Restow lo comprueba con una prueba antes de guardarlo. Los inquilinos que lo usan siguen separados por su propio prefijo y su propia clave. Un repositorio puede ser:

• Un disco local.
• Almacenamiento de objetos compatible con S3, con un preajuste de Hetzner Object Storage. Tiene un selector de ubicación (Falkenstein, Núremberg, Helsinki) que fija a la vez el endpoint y la región, y la detección de Object Lock acepta las respuestas de servicios compatibles con S3 como Hetzner. Con Object Lock en el bucket, también puede alojar copias inmutables, véase más abajo.
• NFS, añadido desde la interfaz web en Instalación, Recursos de red, o mediante una dirección NFS en el campo de ruta de un repositorio de directorio (por ejemplo 192.168.1.10:/export/backup, nas.local:/volume1/restow o una dirección nfs://). El propietario del proveedor puede probarla y montarla allí mismo, y Restow rellena la ruta. Si hay trabajos en ejecución, el montaje espera a que no haya ninguno y puede cancelarse.

NFS pasa por el contenedor montador opcional (docker compose --profile mounts up -d mounter, o la opción del instalador --with-mounter). El montador comprueba un recurso antes de escribir docker-compose.override.yml, reinicia los servicios api y worker y revierte si falla, y el actualizador lo mueve con cada actualización firmada.

Desde la 0.3.6, cuando el montador no está en marcha, la página de recursos de red muestra el comando para iniciarlo, que empieza por el directorio de la instalación. Si el docker-compose.yml de la instalación es anterior al montador, la página lo dice y muestra el comando del instalador: al volver a ejecutar install.sh, sustituye el archivo por el de la versión, conserva el antiguo como copia y deja .env como está.

Desde la 0.3.6, el montaje de una exportación NFS que no existe en el servidor lo dice con claridad: «La ruta de exportación … no existe en …», y explica cómo encontrar la correcta. Lo que el servidor exporta se ve con showmount -e <servidor>. En una NAS Synology la ruta empieza por el volumen, por ejemplo /volume1/restow. Con NFSv4 algunos servidores muestran sus exportaciones bajo una pseudo-raíz, con otras rutas; pruebe entonces la versión 3 de NFS. Antes, el montaje terminaba con un escueto «No such file or directory».

Dónde acaban las copias, y el cambio del destino principal

Desde la 0.4.2, Restow nombra el repositorio principal efectivo del inquilino allí donde se configura o inicia una copia: en la página de un invitado y su diálogo «Copiar ahora», en los diálogos de trabajos y de conexión de Proxmox VE, en la página de un equipo y de un recurso compartido y en los editores de trabajos, con el valor por defecto de la instalación en el disco local del servidor resaltado. La sección Repositorios y los diálogos que añaden nodos de Proxmox VE, equipos y recursos compartidos avisan «Las copias acaban en el propio disco del servidor» cuando el repositorio principal es un directorio en un disco del propio servidor de Restow, no un recurso de red: si ese servidor o su disco falla, las copias se pierden con él.

Desde la 0.4.5 Restow dice además cuándo el directorio está en el disco del sistema del servidor, el disco bajo el sistema operativo, Docker y la base de datos: un disco del sistema lleno detiene todo, no solo las copias. La api lo reconoce desde dentro de su contenedor por el dispositivo y el dispositivo de bloques de la ruta, incluidos el valor por defecto de la instalación y los recursos del montador. La página Repositorios, la línea «Las copias van a:» de los editores de trabajos (con una insignia «Disco del sistema») y el mosaico de almacenamiento del panel avisan, y los administradores del proveedor ven en el mosaico el espacio libre, su tendencia de la última semana y cuándo se llenaría el disco. No se bloquea nada.

Las copias de servidores y equipos (véase copia de servidores y equipos), los recursos compartidos (véase recursos compartidos) y los contenedores de Proxmox VE usan un repositorio restic cada uno, también en el principal, y los repositorios de copia no los cubren. Desde la 0.4.2 el cambio del destino principal los tiene en cuenta:

• Trasladar las copias existentes. Una ejecución en segundo plano copia cada pack, manifiesto y clave, los manifiestos de los puntos de restauración de VM y contenedores y los repositorios de restic de contenedores, equipos y recursos compartidos al repositorio nuevo, los verifica por tamaño y SHA-256 como los packs, espera a las copias de contenedores y las ejecuciones de recursos compartidos en curso y solo entonces cambia el repositorio principal. La ubicación antigua sigue conectada en solo lectura hasta que usted la quite, y no se puede quitar mientras sea la única que guarda un repositorio así.
• Mantener las copias existentes donde están no copia nada, y se rechaza mientras haya contenedores o recursos compartidos con repositorios de restic (el diálogo lo muestra desactivado), porque tras un cambio así cada contenedor y cada recurso compartido encontraría un repositorio vacío en el nuevo principal. Antes de la 0.4.2, cada contenedor con un repositorio existente fallaba entonces con «repository does not exist». Promover una copia se rechaza por el mismo motivo.
• Equipos. Mientras un equipo del inquilino esté activo, Restow sigue rechazando cualquier cambio del repositorio principal, porque un agente activo sigue escribiendo en el principal antiguo. Revoque o desinstale primero los equipos, cambie el repositorio principal (un traslado copia también los repositorios de los equipos revocados) y vuelva a registrar los equipos; así se crean repositorios nuevos en el nuevo principal. Con «mantener», los repositorios de los equipos revocados se quedan en el destino antiguo, que sigue siendo un respaldo de solo lectura: se pueden explorar y descargar.

Copias inmutables

Desde la 0.4.0, cada repositorio tiene su propio ajuste de inmutabilidad. Está desactivado hasta que un administrador lo activa, en la tarjeta del repositorio, en Repositorios («Cambiar la inmutabilidad»), y antes de eso no se bloquea nada. Lo que significa depende del tipo de repositorio.

• S3 con Object Lock, en modo compliance o governance, durante 1 a 3650 días. El propio almacenamiento se niega entonces a borrar o sobrescribir una versión bloqueada antes de su fecha, lo pida quien lo pida: Restow, alguien con la clave de acceso de Restow, una cuenta de administrador robada. El modo compliance no lo puede acortar ni levantar nadie, tampoco el propietario del bucket. El modo governance lo puede levantar cualquier cuenta con el permiso de omisión (s3:BypassGovernanceRetention); Restow no lo usa nunca, y su clave de acceso no debería tenerlo. Al activar el ajuste se comprueba el bucket y se rechaza uno sin Object Lock. Object Lock solo se puede activar al crear un bucket: no se puede añadir a uno existente.
• Un directorio (el volumen de Docker, un recurso NFS) recibe solo un retraso de borrado: el propio código de Restow se niega a borrar o sobrescribir un archivo de copia antes de que pase el periodo. Eso protege contra el mal uso de Restow, como una cuenta de administrador robada o una política de retención acortada para borrar puntos de restauración. No protege contra quien tenga acceso al servidor o al recurso, y la interfaz dice que no es inmutabilidad. Para una inmutabilidad real en local, use un servicio S3 con Object Lock en una máquina aparte, como repositorio o como copia.

Qué se bloquea y qué no

Se bloquean los paquetes, los manifiestos confirmados y las claves envueltas del almacén de fragmentos (Microsoft 365, IMAP y los discos de las VM de Proxmox VE, y el contenido de los mensajes del archivo, que está en el mismo almacén) y los objetos data, snapshots, keys y config de cada repositorio restic (servidores y equipos, recursos compartidos, contenedores de Proxmox VE). No se bloquean los puntos de control, el área de preparación, las exportaciones y las descargas, ni los archivos locks e index de restic; restic puede reconstruir el índice a partir de los paquetes bloqueados. Los registros de los elementos del archivo conservan su propia retención, como antes.

Cómo sigue el bloqueo a los datos

Cada objeto bloqueado se escribe con una fecha de fin de retención igual al periodo más 7 días. Como la deduplicación permite que un punto de restauración nuevo se apoye en paquetes escritos hace meses, la tarea diaria de retención renueva el bloqueo de cada objeto que sigue en uso cuando la última renovación completa tiene 6 días; lo que necesita un punto de restauración queda así bloqueado al menos el periodo a partir de hoy. Cuando la retención o la recolección de basura encuentra un objeto aún bloqueado, el borrado cuenta como «todavía no»: el punto de restauración sigue visible y se puede restaurar, y el espacio vuelve cuando el bloqueo ha vencido, hasta el periodo más 7 días después.

Qué ve usted, y quién puede cambiarlo

La tarjeta del repositorio muestra el ajuste con palabras, la última renovación y la última comprobación, y pone las advertencias primero: objetos sin bloqueo, un modo más débil que el configurado, una renovación atrasada o fallida, y borrados que esperan a su bloqueo. «Comprobar ahora» y la tarea diaria de retención preguntan al almacenamiento por la retención de una muestra de objetos recientes. Los puntos de restauración muestran «Inmutable hasta» con una fecha, en verde solo cuando el propio almacenamiento ha comunicado un bloqueo compliance; governance y un retraso de borrado se muestran en neutro. También avisan el mosaico de almacenamiento del panel y la vista de proveedor. Aumentar la protección está abierto a quien pueda configurar el repositorio. Reducirla (menos días, un modo más débil, desactivarla) es cosa del propietario del proveedor con un inicio de sesión de los últimos diez minutos, y vale solo para los datos escritos a partir de entonces. Cada cambio y cada comprobación quedan en el registro de auditoría.

Contra qué no protege

• Quien controle Restow puede dejar de escribir bloqueos nuevos y detener la renovación. Lo que estaba bloqueado sigue bloqueado hasta su fecha, pero las copias nuevas posteriores no están protegidas.
• Un bloqueo governance lo levanta cualquier cuenta con el permiso de omisión. Dé a la clave de acceso de Restow una política sin él, o use el modo compliance.
• Quien tenga la clave de Restow puede ocultar objetos tras marcadores de borrado o escribir versiones basura encima. Las versiones bloqueadas siguen ahí y se pueden recuperar quitando las versiones o marcadores más nuevos.
• La clave maestra no está en el bucket. Guarde una copia lejos del servidor, o los datos bloqueados no se podrán abrir.

La clave de acceso de un repositorio S3 inmutable necesita s3:GetBucketObjectLockConfiguration, s3:PutObjectRetention, s3:GetObjectRetention, s3:ListBucketVersions y s3:DeleteObjectVersion, y no debería tener s3:BypassGovernanceRetention, s3:PutBucketObjectLockConfiguration ni s3:PutBucketVersioning.

Los endpoints S3 deben usar HTTPS

Un repositorio S3 envía sus firmas de acceso y cada paquete al servicio de almacenamiento, por lo que desde la 0.4.0 se rechaza un endpoint nuevo o modificado por http:// sin cifrar, también para los administradores del proveedor y el valor predeterminado de la instalación. La única excepción es la propia máquina (localhost, 127.0.0.1, [::1]). Los endpoints guardados antes siguen funcionando, así que ninguna copia se detiene con una actualización: su tarjeta de repositorio, Instalación, Repositorio predeterminado y cada prueba dicen en rojo que deberían pasar a HTTPS, y cambiar su ubicación exige https://. Los entornos de prueba y desarrollo pueden aceptar HTTP sin cifrar con S3_ALLOW_INSECURE=true; no lo active nunca en producción.

Cifras de almacenamiento y espacio en disco

Desde la 0.4.1, la cifra «Almacenado» (el mosaico del panel, Repositorios, Uso, las estadísticas y la API) suma los repositorios restic de servidores y equipos, recursos compartidos y contenedores de Proxmox VE al almacén de fragmentos; antes contaba solo el almacén de fragmentos, así que un inquilino con 10 GB de copias de contenedores veía «Almacenado 10,9 kB». La tarjeta de uso muestra cuánto está en el almacén de fragmentos y cuánto en repositorios restic. El ahorro por deduplicación, el crecimiento y el gráfico, ahora llamado «Almacén de fragmentos por día», siguen siendo cifras del almacén de fragmentos, porque los repositorios restic no guardan historial de tamaño, y «Datos protegidos» sigue contando solo las fuentes del almacén de fragmentos.

Desde la 0.4.0, el panel muestra el crecimiento del almacenamiento para 1 semana, 1 mes, 3 meses o 1 año, a partir de 3 meses con la estimación como una banda entre el crecimiento más lento y el más rápido, y cuándo se llena el repositorio a ese ritmo donde se conoce su espacio libre. Cada 15 minutos la API comprueba además el disco bajo la base de datos y bajo el repositorio local predeterminado, y avisa a los administradores del proveedor por debajo de una décima parte libre, y siempre por debajo de 5 GiB. Desde la 0.4.5 vigila también el disco del sistema del servidor con la misma regla.

La comprobación del almacenamiento: dañado no es lo mismo que ilegible

La comprobación del almacenamiento relee packs y los compara con el tamaño y la suma de comprobación registrados: una muestra cada semana y todos los packs cada mes, y «Preparación de recuperación › Integridad del almacenamiento» puede iniciar a mano una muestra, una comprobación completa o una nueva comprobación. Desde la 0.4.2 distingue dos cosas. Un pack está dañado cuando todos los repositorios respondieron con un daño (falta, tamaño incorrecto, suma de comprobación distinta, no es un pack válido o contenido que difiere del índice); cada objeto que lo usa pasa de inmediato a «No restaurable». Un pack está temporalmente ilegible cuando un repositorio no se pudo leer en ese momento, lo que no demuestra nada sobre los datos: una descarga cortada a mitad de transferencia, una conexión restablecida, un tiempo de espera agotado, S3 pidiendo ir más despacio o acceso denegado. La comprobación lee primero de nuevo ese pack, entero, hasta tres veces, y enumera lo que sigue ilegible como «temporalmente ilegible», con el error, en cuántas comprobaciones seguidas no se pudo leer y cuándo la primera y la última vez. Los objetos que lo usan reciben «Atención». Pasan a «No restaurable» solo cuando un pack está demostradamente dañado o no se pudo leer en 3 comprobaciones seguidas a lo largo de al menos 24 horas. Cada comprobación posterior lee primero los packs marcados, «Volver a comprobar estos packs» lee de nuevo solo esos, y cuando se leen intactos otra vez el hallazgo termina y las comprobaciones de restauración propias de los objetos vuelven a calificarlos. Las lecturas de S3, también las restauraciones y las comprobaciones de restauración, reanudan además una descarga que se corta, desde el primer byte que falta.

Límites indicados, no ocultos

• El traslado de los repositorios de restic, la verificación por SHA-256 y la reanudación de las lecturas de S3 se probaron con un servicio S3 simulado y directorios locales, no con un proveedor de S3 real. Una copia de contenedor que empieza en la ventana de caché de almacenamiento de un minuto de la API alrededor del cambio todavía puede escribir en el principal antiguo; la comprobación de repositorio de la siguiente copia encuentra el repositorio en el nuevo principal.
• El montaje de un recurso NFS desde la interfaz web, o desde el campo de ruta de un repositorio, se probó con simulaciones, no contra un servidor NFS real. Mientras un montaje espera a los trabajos en ejecución, los trabajos nuevos siguen arrancando, así que en un servidor que nunca queda libre sigue esperando.
• En repositorios locales y NFS hay un retraso de borrado que Restow impone por sí mismo, no inmutabilidad: quien tenga acceso al servidor o al recurso puede borrar los archivos igualmente. Las copias inmutables necesitan un bucket S3 creado con Object Lock. El repositorio predeterminado de la instalación no se puede hacer inmutable: dé al inquilino un repositorio propio o una copia inmutable.
• Las copias inmutables se probaron con un servicio S3 simulado con Object Lock, todavía no con un servicio S3 real con Object Lock ni con un bucket real de Hetzner. Un inquilino cuya planificación de retención se eliminó no se renueva, y el espacio de los datos borrados vuelve solo cuando ha vencido su bloqueo. Cómo se comporta Restow con una retención predeterminada de Object Lock para todo el bucket no está probado.
• Restow reconoce una exportación NFS inexistente por el texto de error de Docker, y ese texto procede de la documentación de Docker, no de un montaje fallido real.
• El preajuste de Hetzner no se probó contra un bucket real de Hetzner.

Cómo se compara esto con una copia de seguridad alojada en SaaS

La mayoría de los productos de copia de seguridad de Microsoft 365 alojados por un proveedor ponen sus datos en la nube propia del proveedor por definición (eso es lo que significa «alojado»), y varios son genuinamente buenos operando esa infraestructura; véase, en inglés, las comparativas de proveedores para lo que cada uno documenta realmente sobre dónde viven los bytes. La respuesta de Restow es estructural, no una promesa: no está construido para operar esa nube en primer lugar, así que no hay nada más en lo que confiar aparte de su propia elección de almacenamiento y del cifrado que Restow aplica a lo que entra en él (véase cifrado y gestión de claves).

Preguntas frecuentes

Por qué importa aportar su propio almacenamiento, en profundidad →

Más en Aprender: la regla 3-2-1 y dónde encaja un repositorio de copia →

Más en Aprender: elegir almacenamiento para copias de seguridad, con disco local, NAS, S3 y cinta comparados →

Más en Aprender: copias inmutables, WORM y air gap →