# Restauración en vivo (Live restore)


Por defecto, cuando el demonio de Docker finaliza, detiene los contenedores en ejecución. Puedes configurar el demonio para que los contenedores sigan ejecutándose si el demonio deja de estar disponible. Esta funcionalidad se llama _restauración en vivo (live restore)_. La opción de restauración en vivo ayuda a reducir el tiempo de inactividad de los contenedores debido a caídas del demonio, cortes planificados o actualizaciones.

> [!NOTE]
>
> La restauración en vivo no es compatible con contenedores de Windows, pero sí funciona para contenedores de Linux que se ejecutan en Docker Desktop para Windows.

## Habilitar la restauración en vivo

Hay dos formas de habilitar la configuración de restauración en vivo para mantener los contenedores activos cuando el demonio no está disponible. **Realiza solo una de las siguientes acciones**:

- Añade la configuración al archivo de configuración del demonio. En Linux, la ubicación predeterminada es `/etc/docker/daemon.json`. En Docker Desktop para Mac o Docker Desktop para Windows, selecciona el icono de Docker en la barra de tareas y luego selecciona **Settings** -> **Docker Engine**.

  - Utiliza el siguiente JSON para habilitar `live-restore`.

    ```json
    {
      "live-restore": true
    }
    ```

  - Reinicia el demonio de Docker. En Linux, puedes evitar un reinicio (y evitar cualquier tiempo de inactividad para tus contenedores) recargando el demonio de Docker. Si utilizas `systemd`, usa el comando `systemctl reload docker`. De lo contrario, envía una señal `SIGHUP` al proceso `dockerd`.

- Si lo prefieres, puedes iniciar el proceso `dockerd` manualmente con la opción `--live-restore`. No se recomienda este enfoque porque no configura el entorno que `systemd` u otro gestor de procesos usaría al iniciar el proceso de Docker. Esto puede causar un comportamiento inesperado.

## Restauración en vivo durante actualizaciones

La restauración en vivo te permite mantener los contenedores en ejecución durante las actualizaciones del demonio de Docker, pero solo es compatible cuando se instalan versiones de parches (`YY.MM.x`), no para actualizaciones mayores del demonio (`YY.MM`).

Si te saltas versiones durante una actualización, es posible que el demonio no restaure su conexión con los contenedores. Si el demonio no puede restaurar la conexión, no podrá gestionar los contenedores en ejecución y tendrás que detenerlos manualmente.

## Restauración en vivo tras el reinicio

La opción de restauración en vivo solo funciona para restaurar contenedores si las opciones del demonio, como las direcciones IP del puente (bridge) y el controlador de gráficos (graph driver), no han cambiado. Si alguna de estas opciones de configuración a nivel del demonio ha cambiado, es posible que la restauración en vivo no funcione y que tengas que detener manualmente los contenedores.

## Impacto de la restauración en vivo en los contenedores en ejecución

Si el demonio está inactivo durante mucho tiempo, los contenedores en ejecución pueden llenar el registro FIFO que el demonio lee normalmente. Un registro lleno impide que los contenedores registren más datos. El tamaño del búfer predeterminado es de 64 KB. Si los búferes se llenan, debes reiniciar el demonio de Docker para vaciarlos.

En Linux, puedes modificar el tamaño del búfer del kernel cambiando `/proc/sys/fs/pipe-max-size`. No puedes modificar el tamaño del búfer en Docker Desktop para Mac o Docker Desktop para Windows.

## Restauración en vivo y el modo Swarm

La opción de restauración en vivo solo se refiere a contenedores independientes y no a servicios de Swarm. Los servicios de Swarm son gestionados por los administradores (managers) de Swarm. Si los administradores de Swarm no están disponibles, los servicios de Swarm continúan ejecutándose en los nodos trabajadores (workers) pero no se pueden gestionar hasta que haya suficientes administradores de Swarm disponibles para mantener el cuórum.