Primeros pasos

Antes de empezar

• Un servidor Linux amd64 (x86_64) o arm64 (aarch64): Debian, Ubuntu, RHEL y derivados (Rocky, AlmaLinux, Fedora), Alpine. Kernel Linux 3.2 o más reciente; los sistemas de 32 bits no son compatibles. Con systemd, o cron con su demonio en marcha (en Alpine: rc-update add crond default && rc-service crond start).
• En la familia RHEL, sudo no busca en /usr/local/bin: escribe sudo /usr/local/bin/neverwiped …, o trabaja en un shell root (sudo -i).
• Acceso root, o sudo.
• curl o wget, y sha256sum u openssl (casi todas las distribuciones los traen).
• Salida HTTPS (puerto 443) hacia https://neverwiped.com (la plataforma), https://storage.neverwiped.com (el almacenamiento de las copias, en Francia) y https://github.com (restic se descarga una vez, al instalar, y se comprueba su huella SHA-256).
• Una cuenta de NeverWiped con el correo confirmado: la prueba gratis dura 14 días, sin tarjeta. Después, una clave de API: panel › Claves de API › Crear. Empieza por nw_acc_ y solo se muestra una vez.

1. Instalar con un comando

En el servidor, como root:

curl -fsSL https://neverwiped.com/install.sh | sh

El script te pide la clave de API, te enseña qué va a copiar y espera tu permiso. Para responderlo todo por adelantado (scripts, agentes de IA):

curl -fsSL https://neverwiped.com/install.sh | sh -s -- --api-key "$NEVERWIPED_API_KEY" --yes

¿No eres root? Cambia | sh por | sudo sh. ¿Sin curl? wget -qO- https://neverwiped.com/install.sh | sh.

Más rápido: el panel de tu área de cliente prepara este comando con una nueva clave de API ya incluida (… | sh -s -- --api-key CLAVE). Un clic, un pegado: el script solo pregunta por el plan y la primera copia. La clave queda en el historial de tu shell; solo sirve para registrar servidores, y puedes revocarla en Claves de API cuando tus servidores estén instalados, sin parar sus copias.

Lo que pasa, en orden:

1. El script descarga el agente para tu arquitectura, comprueba su huella SHA-256 y lo instala en /usr/local/bin/neverwiped.
2. neverwiped install descarga restic 0.18.1 (huella comprobada), detecta tus sitios, bases de datos y volúmenes Docker, y muestra el plan.
3. Tras tu permiso, registra el servidor, crea el repositorio cifrado con una clave generada en el servidor y muestra una sola vez la clave de recuperación.
4. Programa las copias según tu plan y lanza la primera.

Para ajustar el plan, añade opciones después de --yes: --include /data, --exclude "*.log", --no-databases, --no-docker. Mira la referencia de comandos.

Tamaño y exclusiones antes de la primera copia

Antes de pedirte que aceptes el plan, la instalación lo mide: tamaño y número de archivos de cada carpeta y volumen Docker una vez aplicadas las exclusiones, las carpetas más grandes, el tamaño de los archivos de las bases locales y lo que quitaría cada preajuste de exclusiones. Solo lee tamaños (ningún contenido) y no envía nada. Se detiene a los 90 segundos y entonces dice «al menos»; --no-estimate la omite.

Puedes lanzar la misma medida antes de suscribirte, con las mismas opciones que la instalación. No se registra nada ni se hace ninguna llamada de red:

neverwiped estimate
neverwiped estimate --preset logs --exclude /var/www/site/tmp
neverwiped estimate --json

La cifra es el tamaño antes de compresión y deduplicación: la primera copia envía como mucho esto. El texto y las bases suelen comprimirse bien, las fotos, vídeos y archivos comprimidos casi nada. Las exportaciones de bases no se cuentan: la estimación muestra en su lugar el tamaño de los archivos de las bases en disco, y una exportación suele ser más pequeña. Para las bases en Docker no se mide el tamaño de la exportación. Compara el total con el espacio de cada plan en la página de precios.

Una vez registrado el servidor, la instalación compara la estimación con el espacio que queda en tu suscripción. Si los archivos y volúmenes por sí solos lo superan, pregunta antes de la primera copia, con «no» como respuesta por defecto. Con --yes no lanza la primera copia, para que no se detenga a medias en la cuota. Las copias programadas siguen activas.

Preajustes. Ninguno se aplica por defecto. Añade uno con --preset NOMBRE (repetible, o --preset logs,build, o --preset all), con estimate o con install. La estimación propone los que ahorrarían al menos 100 MiB en tu servidor.

Elige archives solo si esos archivos son copias de datos que el plan ya respalda: un archivo que sea tu única copia de algo dejaría de respaldarse. Lo mismo con logs si necesitas los registros antiguos (una auditoría, por ejemplo). Los patrones siguen la sintaxis de restic: un patrón sin / al principio se aplica a cualquier profundidad. Como todas las opciones, los preajustes no se recuerdan: repítelos cuando vuelvas a ejecutar neverwiped install.

2. Guardar la clave de recuperación

Al final de la instalación el agente muestra este recuadro. El ejemplo viene de una sesión en francés; en español dice: «CLAVE DE RECUPERACIÓN: apúntala ahora, fuera de este servidor. No se volverá a mostrar y NeverWiped no la conoce. Sin ella, si pierdes este servidor, tus copias no se pueden leer».

========================================================================
CLÉ DE RÉCUPÉRATION — notez-la maintenant, hors de ce serveur.

    Ab3dEf-GhJkMn-PqRsTu-VwXyZa-b2c3d4-e5f6g7

Serveur : web-01 (identifiant 0b6a3c1e-2f4d-4e8a-9c7b-5d1e2f3a4b5c). Code de contrôle de cette clé : 4342-B317.
Notez le nom du serveur et le code de contrôle à côté de la clé : chaque serveur a sa propre clé de récupération.
Elle ne sera plus jamais affichée et NeverWiped ne la connaît pas.
Sans elle, si ce serveur est perdu, vos sauvegardes sont illisibles.
========================================================================

Guárdala ahora mismo en tu gestor de contraseñas, no en el servidor. Por qué importa: cifrado y clave de recuperación.

Después prueba la copia anotada: sudo neverwiped recovery-key check (la clave no se envía a ningún sitio). ¿La pierdes más tarde? Mientras el servidor siga funcionando, sudo neverwiped recovery-key new crea una nueva: clave de recuperación perdida.

3. La primera copia

La instalación la lanza por ti (salvo con --no-backup). Lanza una cuando quieras:

neverwiped backup now

Sauvegarde démarrée (manual)
Export postgresql (toutes les bases)…
Sauvegarde réussie en 2s : 2,0 Mo ajoutés, 5,3 Mo stockés au total, instantané a31a3fb5

«Copia correcta en 2 s: 2,0 MB añadidos, 5,3 MB guardados en total, instantánea a31a3fb5». Solo se envían los cambios. Después, las copias se hacen solas: cada noche en Pro y Business, una vez por semana en Essentiel, a una hora fija entre la 1 y las 6 de la madrugada aproximadamente, hora del servidor. Se ejecutan con prioridad baja; para limitar también su velocidad de envío o su CPU, consulta Velocidad, CPU y prioridad.

4. Comprobar el estado

neverwiped status
neverwiped list

status muestra el servidor, lo que se copia, tu plan, si las copias están activas, el espacio usado y la última copia:

Serveur      : vps-prod (identifiant be1e7955-1dd6-4211-8002-7746d6ede9e2)
Plateforme   : https://neverwiped.com
Agent        : neverwiped 0.2.0, restic 0.18.1
Dossiers     : /etc, /var/spool/cron, /var/www
Base         : postgresql (locale)
Abonnement   : Essentiel (trialing)
Sauvegardes  : hebdomadaire, actives
Espace       : 5,3 Mo utilisés sur 5,0 Go
Dernière     : 2026-11-04 02:16
Planification: minuteur systemd (…)

Qué mirar: Sauvegardes (copias) dice actives, Dernière (última) es una fecha reciente y Planification (programación) encontró un temporizador o una tarea cron. También recibes un correo si una copia falla o si no hay ninguna durante un tiempo: mira estado y avisos.

5. Restaurar

Empieza por la lista de copias; las fechas están en hora del servidor.

neverwiped list

Todas las restauraciones de abajo van a una carpeta aparte: no se sobrescribe nada en el servidor. Las rutas originales se recrean debajo: /var/www/site/index.html vuelve como /root/restore/var/www/site/index.html.

Un archivo

neverwiped restore latest --include /var/www/site/wp-config.php --target /root/restore
ls -l /root/restore/var/www/site/wp-config.php
cp -a /root/restore/var/www/site/wp-config.php /var/www/site/wp-config.php
rm -rf /root/restore

--include recibe la ruta completa tal como estaba en el servidor; mayúsculas y minúsculas cuentan. Si ls responde No such file (o No existe el archivo), esa ruta no está en esta copia: revisa cómo está escrita o elige una copia más antigua en neverwiped list. cp -a conserva el propietario y los permisos del archivo. Borra después la carpeta: si no, la copia se vuelve a guardar en la siguiente copia si /root forma parte de tu plan.

Una carpeta

Elige la noche anterior al problema (aquí el 3 de noviembre), compara y copia lo que necesites:

neverwiped restore 2026-11-03 --include /var/www/site/uploads --target /root/restore
diff -rq /root/restore/var/www/site/uploads /var/www/site/uploads
cp -a /root/restore/var/www/site/uploads/. /var/www/site/uploads/

Una fecha es la última copia de ese día. También puedes dar latest, un minuto ("2026-11-03 22:59") o un identificador de neverwiped list. Añade --yes si la carpeta no está vacía.

Una base de datos

Cada copia contiene un volcado de las bases encontradas, en archivos .sql, hecho mientras funcionan. Para PostgreSQL es pg_dumpall: todas las bases, cada una coherente por sí sola, más los roles. Para MySQL y MariaDB es mysqldump (o mariadb-dump) --all-databases --single-transaction: todas las bases leídas de una misma instantánea sin bloquear el sitio, más los usuarios y sus permisos, procedimientos, triggers y eventos. Una exportación cortada antes del final hace fallar la copia; nunca se guarda como buena. No se reimporta nada automáticamente, a propósito.

Qué momento. Vuelves a la hora de una copia, no a cualquier instante entre dos: cada noche en Pro y Business, una vez por semana en Essentiel. Los cambios hechos después de la última copia no están en ninguna. Antes de una operación arriesgada (una migración, una importación grande), lanza neverwiped backup now.

Elige la copia en neverwiped list (hora del servidor) y recupera sus volcados en una carpeta aparte. Indica el minuto que muestra list, un día (la última copia de ese día) o un id:

neverwiped list
neverwiped restore "2026-11-03 02:16" --include /var/lib/neverwiped/dumps --target /root/restore
ls -l /root/restore/var/lib/neverwiped/dumps

Para antes la aplicación que escribe en la base. Los archivos solo los puede leer root: los lee tu shell de root (<); psql -f lanzado como postgres no puede abrirlos.

Una sola base PostgreSQL dañada, las demás bien (un DELETE de más, una migración fallida). No reimportes el archivo entero encima de bases que todavía existen: vuelve a añadir filas a sus tablas, o se para a medias con errores. Saca la parte de la base que necesitas (aquí shop), aparta la base dañada con otro nombre e importa esa parte sola:

sed -n '/^-- Database "shop" dump$/,/^-- PostgreSQL database dump complete$/p' /root/restore/var/lib/neverwiped/dumps/postgresql-local.sql > /root/restore/shop.sql
grep -c '^CREATE DATABASE' /root/restore/shop.sql
runuser -u postgres -- psql -d postgres -c 'ALTER DATABASE shop RENAME TO shop_damaged'
runuser -u postgres -- psql -v ON_ERROR_STOP=1 -d postgres < /root/restore/shop.sql

grep -c debe mostrar 1. 0 significa que esta copia no tiene ninguna base con ese nombre: lístalas con grep '^-- Database' /root/restore/var/lib/neverwiped/dumps/postgresql-local.sql. Si el cambio de nombre responde que la base «is being accessed by other users», la aplicación sigue conectada. ON_ERROR_STOP=1 se para en el primer error en vez de seguir. Comprueba tu aplicación, copia de shop_damaged lo reciente que aún necesites y bórrala con runuser -u postgres -- psql -d postgres -c 'DROP DATABASE shop_damaged'. Sirve para cualquier base salvo postgres y template1, que un volcado nunca recrea: para esas, usa el archivo entero en un servidor nuevo.

Una base MySQL o MariaDB dañada, las demás bien. El archivo contiene todas las bases una tras otra, y cada tabla empieza con DROP TABLE IF EXISTS. Toma los ajustes del principio del archivo (juego de caracteres, zona horaria, control de claves foráneas) y la parte de tu base (aquí shop), guarda aparte la base dañada y luego importa esa parte:

D=/root/restore/var/lib/neverwiped/dumps
grep '^-- Current Database' $D/mysql-local.sql
{ sed -n '1,/^-- Current Database: /p' $D/mysql-local.sql; sed -n '/^-- Current Database: `shop`$/,/^-- Current Database: /p' $D/mysql-local.sql; } > /root/restore/shop.sql
grep -c '^USE `shop`;' /root/restore/shop.sql
mysqldump --single-transaction --routines --events --triggers --databases shop > /root/restore/shop-damaged.sql
mysql < /root/restore/shop.sql

grep -c debe mostrar 1. 0 significa que esta copia no tiene ninguna base con ese nombre: el primer grep lista las que tiene. mysql se para en el primer error. Cada tabla de la copia se borra y se recrea tal como estaba; una tabla creada después se queda como está; los usuarios y contraseñas no se tocan. Comprueba tu aplicación: shop-damaged.sql contiene la base tal como estaba justo antes, por si necesitas algo reciente. En MariaDB 11 sin los comandos mysql y mysqldump, escribe mariadb y mariadb-dump. Cuando root tiene contraseña, estos comandos la leen de /root/.my.cnf; en una Debian antigua que se conecta con /etc/mysql/debian.cnf, añade --defaults-extra-file=/etc/mysql/debian.cnf justo después de mysql y mysqldump.

Todas las bases han desaparecido, o es un servidor nuevo: reimporta el archivo entero. También recrea los roles; donde un rol ya existe verás role "…" already exists, sin consecuencias.

# PostgreSQL en el servidor (todas las bases, roles incluidos)
runuser -u postgres -- psql postgres < /root/restore/var/lib/neverwiped/dumps/postgresql-local.sql
# MySQL o MariaDB en el servidor
mysql < /root/restore/var/lib/neverwiped/dumps/mysql-local.sql

En Alpine, que no tiene runuser, usa su postgres -c 'psql postgres' con el mismo < archivo, y lo mismo para las demás líneas de psql.

Para MySQL y MariaDB, el archivo entero también trae de vuelta los usuarios, sus contraseñas y permisos tal como estaban en esa copia (una contraseña cambiada después vuelve a ser la antigua), y los activa (FLUSH PRIVILEGES). Impórtalo en el mismo producto (MySQL en MySQL, MariaDB en MariaDB), en la misma versión o una más reciente; en MariaDB, ejecuta después mariadb-upgrade si la versión es más reciente. De MySQL a MariaDB o al revés, importa las bases una a una como arriba y vuelve a crear los usuarios. Dos mensajes posibles: Unknown command '\-' en la línea 1 significa que el archivo viene de un MariaDB reciente y tu cliente es más antiguo, o es el de MySQL: borra esa primera línea con sed -i '1{/999999/d}' <archivo> e importa de nuevo. Got a packet bigger than 'max_allowed_packet': añade --max-allowed-packet=1G después de mysql; si es el servidor el que lo rechaza, sube max_allowed_packet en su configuración.

Tablas MySQL o MariaDB fuera de InnoDB. La instantánea única cubre las tablas InnoDB, el motor por defecto. Si algunas tablas usan MyISAM o Aria, el registro de copias (/var/log/neverwiped.log) lo indica: esas tablas se copian tal como están cuando les llega el turno, no en el mismo instante que el resto. Lístalas todas y conviértelas en un momento tranquilo (la conversión reescribe la tabla):

mysql -e "SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND ENGINE <> 'InnoDB' AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')"
mysql -e 'ALTER TABLE shop.hits ENGINE=InnoDB'

Las bases en Docker vuelven como postgresql-docker-<contenedor>.sql o mysql-docker-<contenedor>.sql; los comandos para contenedores están en la referencia. Los pasos de «una sola base» funcionan igual con docker exec -i <contenedor> sh -c 'exec psql -U "${POSTGRES_USER:-postgres}" -v ON_ERROR_STOP=1 -d postgres' < /root/restore/shop.sql. Para MySQL o MariaDB en un contenedor, prepara shop.sql igual a partir de mysql-docker-<contenedor>.sql e impórtalo con el comando para contenedores de la referencia en lugar de mysql. Al terminar, rm -rf /root/restore: si no, la próxima copia vuelve a guardar los volcados si /root está en tu plan.

Un volumen Docker

Cómo se respalda un volumen. neverwiped status lista tus volúmenes y cómo se toma cada uno:

• en caliente (lo predeterminado para subidas, archivos y configuración): se lee mientras sus contenedores siguen en marcha. En la copia está en /var/lib/docker/volumes/<nombre>/_data.
• copiado con sus contenedores en pausa (propuesto al instalar para Redis, Valkey, MongoDB, Elasticsearch, OpenSearch, InfluxDB, RabbitMQ, Vaultwarden y similares): los contenedores en marcha que usan el volumen se pausan (docker pause: congelados, ni detenidos ni reiniciados), el volumen se copia en el mismo disco, se reanudan y luego se sube la copia. La pausa dura lo que la copia local, unos segundos para unos GB. En la copia está en /var/lib/neverwiped/volumes/<nombre>. La copia es lo que un corte de luz en ese instante dejaría en el disco: una aplicación con diario (Redis, MongoDB, SQLite…) arranca desde ahí como tras un apagado brusco.

La copia en pausa necesita, en el disco de /var/lib/neverwiped, el tamaño del volumen más un 10 % y 1 GB libres, y se detiene a los 5 minutos. Cuando no puede hacerse, el volumen se respalda en caliente esa vez y la copia se marca como fallida con el motivo, para que lo veas. Cambia cómo se toma un volumen con neverwiped install --yes --pause-volume <nombre> o --live-volume <nombre> (repite estas opciones en cada nuevo install). Los volúmenes de contenedores PostgreSQL, MySQL y MariaDB no se copian como archivos: se copia su exportación (Una base de datos). Las carpetas montadas desde el host (./data:/data) se respaldan con esa carpeta, en caliente.

Devolver un volumen. Restáuralo en una carpeta aparte; el CLI muestra dónde ha vuelto:

V=app_uploads
neverwiped restore latest --include /var/lib/docker/volumes/$V/_data --target /root/restore   # volumen en caliente
neverwiped restore latest --include /var/lib/neverwiped/volumes/$V --target /root/restore      # copia en pausa
SRC=/root/restore/var/lib/docker/volumes/$V/_data      # o /root/restore/var/lib/neverwiped/volumes/$V

Después detén lo que lo usa, guarda aparte su contenido actual y copia la copia de seguridad:

docker ps -a --filter volume=$V                 # los contenedores que lo usan
docker compose stop                             # en la carpeta de la aplicación (o: docker stop <contenedor>…)
MP=$(docker volume inspect -f '{{.Mountpoint}}' $V)
mkdir -p /root/volume-before && cp -a "$MP/." /root/volume-before/
test -d "$MP/" && find "$MP" -mindepth 1 -delete
cp -a "$SRC/." "$MP/"
docker compose start                            # (o: docker start <contenedor>…)

Propietarios, permisos y enlaces vuelven como estaban. El volumen ya no existe (servidor nuevo, docker compose down -v): ejecuta antes docker compose up --no-start en la carpeta de la aplicación, que crea el volumen y los contenedores sin arrancarlos, y luego las tres últimas líneas (o docker volume create $V sin Compose). Un volumen con un nombre de 64 caracteres es anónimo: pertenece a un contenedor y cambia de nombre cuando el contenedor se recrea, así que copia en el volumen del nuevo contenedor (docker inspect -f '{{range .Mounts}}{{.Name}} {{end}}' <contenedor>). No restaures un volumen en caliente en su sitio (sin --target) con sus contenedores en marcha: los archivos cambiarían bajo la aplicación y los creados desde la copia seguirían ahí. Cuando todo funcione: rm -rf /root/restore /root/volume-before.

Un servidor entero

El servidor sigue funcionando (actualización fallida, configuración rota): restaura en su sitio. Las rutas guardadas se sustituyen por su versión de esa noche. Para antes tus aplicaciones.

neverwiped restore 2026-11-03

El agente muestra lo que se va a sobrescribir y te pide que escribas RESTAURER («restaurar» en francés). Sin terminal se niega, salvo con --yes, que cuenta como permiso explícito para sobrescribir.

Has perdido el servidor (borrado, disco roto, sin acceso). Necesitas dos cosas: una clave de API de la cuenta (panel › Claves de API › Crear) y tu clave de recuperación. Todo se hace en el servidor nuevo, sin soporte. Instala antes allí tu software base (servidor web, servidor de bases de datos) con el gestor de paquetes, como en el antiguo.

1. Instala solo el agente, sin registrarlo como servidor nuevo:

curl -fsSL https://neverwiped.com/install.sh | NEVERWIPED_NO_SETUP=1 sh

2. Da a este servidor acceso a las copias del servidor perdido:

neverwiped recover

Pide la clave de API, muestra los servidores de tu cuenta (elige el perdido), pide la clave de recuperación (oculta mientras la pegas) y una confirmación. Entonces revoca la credencial de almacenamiento y la clave de agente del servidor perdido: si la máquina antigua sigue funcionando, o vuelve, ya no puede leer ni añadir copias. Tu clave de recuperación pasa a ser la clave de este servidor (/etc/neverwiped/repo.key) y nunca se nos envía; guarda tu copia, no se crea ninguna nueva. Recibes un correo que te lo avisa.

Si la clave se rechaza (la clave de recuperación no abre las copias de …), no se guarda nada en el servidor: comprueba la clave (6 grupos de 6 caracteres) y vuelve a lanzar neverwiped recover. El panel muestra entonces ese servidor con el nombre del servidor nuevo; para indicarlo con --server, usa su identificador.

Con varios servidores, recover compara primero tu clave con el código de control del servidor elegido (el código mostrado con la clave en la instalación y en la página del servidor). Una clave de otro servidor se rechaza antes de revocar nada, y el mensaje indica a qué servidor pertenece. Ver varios servidores.

En un script (sin terminal), pásalo todo como opciones. Pon antes la clave de recuperación en un archivo solo para root (cat, pega, Intro, Ctrl-D), para que no quede en el historial del shell:

umask 077
cat > /root/recovery.key
NEVERWIPED_API_KEY=nw_acc_TU_CLAVE neverwiped recover --server NOMBRE-DEL-SERVIDOR-PERDIDO --recovery-key-file /root/recovery.key --yes
rm -f /root/recovery.key

3. Restaura todo en una carpeta. No se sobrescribe nada en el servidor nuevo:

neverwiped list
neverwiped restore latest --target /root/restore

4. Vuelve a poner lo que necesites. Es una máquina nueva: copia tus carpetas de datos y de aplicaciones, y los archivos de configuración de tu software uno a uno, no el sistema entero. Por ejemplo:

cp -a /root/restore/var/www/. /var/www/
cp -a /root/restore/etc/nginx/sites-available/example.com /etc/nginx/sites-available/

No copies /root/restore/etc encima de /etc ni lances neverwiped restore en su sitio en un servidor nuevo. Traería la red, los discos (fstab) y los ajustes SSH de la máquina antigua, y también /etc/neverwiped, la configuración del agente del servidor perdido cuyas claves recover acaba de revocar: el agente dejaría de funcionar. Después reimporta las bases con las líneas «servidor nuevo» de una base de datos (los archivos están en /root/restore/var/lib/neverwiped/dumps) y arranca tus aplicaciones.

5. Limpia y reanuda las copias en este servidor, en el mismo repositorio (sin servidor nuevo ni clave de recuperación nueva):

rm -rf /root/restore
neverwiped install --yes

Borra antes la carpeta: si no, la copia restaurada entra en la próxima copia si /root está en tu plan. neverwiped list muestra luego las copias del servidor antiguo junto a las nuevas; puedes seguir restaurando desde las antiguas.

Último recurso, restic solo, sin el agente (sin acceso a tu cuenta, por ejemplo): escribe a soporte desde el correo de tu cuenta con el nombre del servidor perdido. Soporte emite una nueva credencial de almacenamiento para ese repositorio, por un canal seguro, e invalida la anterior. Soporte no puede leer tus copias: no tiene la clave. Después, en el servidor nuevo, instala restic 0.18.1 y comprueba su huella (arm64: restic_0.18.1_linux_arm64.bz2, huella 87f53fddde38764095e9c058a3b31834052c37e5826d2acf34e18923c006bd45), y restaura con la clave de recuperación (cambia las mayúsculas por tu clave y la credencial que te dio soporte):

curl -fsSLO https://github.com/restic/restic/releases/download/v0.18.1/restic_0.18.1_linux_amd64.bz2
echo "680838f19d67151adba227e1570cdd8af12c19cf1735783ed1ba928bc41f363d  restic_0.18.1_linux_amd64.bz2" | sha256sum -c
bunzip2 restic_0.18.1_linux_amd64.bz2 && install -m 0755 restic_0.18.1_linux_amd64 /usr/local/bin/restic
umask 077
printf '%s' 'TU-CLAVE-DE-RECUPERACION' > /root/recovery.key
export RESTIC_REPOSITORY='rest:https://USUARIO:CONTRASENA@storage.neverwiped.com/USUARIO/'
export RESTIC_PASSWORD_FILE=/root/recovery.key
restic snapshots
restic restore latest --target /root/restore
rm -f /root/recovery.key

Después sigue desde el paso 4.

Sin la clave de recuperación y sin el servidor antiguo, nadie puede leer las copias, tampoco nosotros. Es el precio de un cifrado que no podemos abrir.

Con un agente de IA: el plan y luego el permiso

Cuando un agente de IA (Claude Code, Codex, Cursor) restaura por ti, haz que primero pregunte con un plan. --plan no escribe nada, no toma el bloqueo y no contacta con NeverWiped:

neverwiped restore latest --include /var/www/site/uploads --target /root/restauracion --plan

Muestra qué copia (fecha e identificador), qué rutas, dónde escribiría (una carpeta aparte, vacía o no, o en su sitio), un código de aprobación y el comando exacto que lanza esta restauración. El agente te enseña ese plan y espera. Tras tu permiso, lanza el comando mostrado sin cambiarlo, por ejemplo (el identificador y el código son ejemplos):

neverwiped restore 8b28999a --include /var/www/site/uploads --target /root/restauracion --approve K7QD-2M9F

Antes de escribir nada, el agente de NeverWiped vuelve a calcular el código a partir de la copia, la carpeta y las rutas. Si alguna difiere del plan que aprobaste (latest apunta ahora a una copia más reciente, se cambió una carpeta o una ruta), lo rechaza y no se escribe nada: pide un plan nuevo. El comando mostrado nombra la copia por su identificador: una copia que se haga entre tu permiso y la restauración no cambia lo que vuelve.

El código no es una contraseña y no impide a nadie con root restaurar sin él. Vincula tu permiso a un plan. Copiar archivos de /root/restauracion encima de los archivos en uso es un paso aparte, y un permiso aparte. La página de agentes de IA tiene un prompt para ello.

6. Prueba una restauración hoy

Una copia que nunca has restaurado es una esperanza. Hazlo el primer día y luego una vez al mes:

neverwiped restore latest --target /root/test-restore --yes
ls -R /root/test-restore | head
rm -rf /root/test-restore

Después comprueba que encuentras la clave de recuperación en tu gestor de contraseñas.

Siguiente

• Cifrado y clave de recuperación: lo que podemos hacer y lo que no.
• Almacenamiento, retención y purga: solo-añadir, y la ventana de una hora.
• Lo que llega a tu servidor, y cómo desinstalar.
• Todos los comandos y opciones, todos los mensajes de error.