Restic: Copias de seguridad sin cifrar

He escuchado esta solicitud de función varias veces y tenía en mente que había un problema al respecto. Como parece que no puedo encontrarlo, esta solicitud de función se rastrea aquí. La versión corta es: Es posible que en algún momento agreguemos una opción para deshabilitar el cifrado, pero eso no está en la hoja de ruta en este momento.

La versión larga es:

• El cifrado ya no es caro, al menos no si tiene AES-NI (cifrado acelerado por hardware), que es bastante común hoy en día (al menos en computadoras portátiles y servidores)
• restic no solo se preocupa por el cifrado, sino también por la autenticidad y la firma de los datos. Necesitamos encontrar una manera de implementar esto sin cifrado, por lo que necesitaremos mantener una clave / contraseña de todos modos.
• Una vez que tenemos una ruta de código que permite copias de seguridad no cifradas, existe la posibilidad de que los atacantes encuentren una manera de engañar a un cliente para que guarde los datos sin cifrar en un repositorio cifrado (originalmente). Eso sucedió antes con otros programas de respaldo, por lo que debemos tener mucho cuidado, lo que requiere tiempo y recursos que no tenemos en este momento.

Puedo agregar más puntos cuando los encuentre.

Una razón alternativa para querer copias de seguridad no cifradas (localmente) es que varios usuarios puedan compartir un repositorio central; es decir, en mi servidor doméstico me gustaría enviarle una copia de seguridad a través de HTTPS, pero dejar que todos se deduplican en un repositorio común. incluso si se presentan lógicamente separados de los usuarios individuales.

Existe la posibilidad de que los atacantes encuentren una manera de engañar a un cliente para que guarde los datos sin cifrar en un repositorio (originalmente) cifrado.

Hm, pensé que la idea era que un repositorio esté cifrado o no, por lo que no sería posible guardar datos sin cifrar en un repositorio cifrado ... Y si un repositorio cifrado se reemplaza de alguna manera por uno no cifrado con el mismo nombre y ubicación, el usuario debe notar que no se ha solicitado contraseña. Tal vez se pueda imprimir una advertencia en texto rojo parpadeante en negrita, que el repositorio no está encriptado :).

@wrouesnel ya puede hacerlo, ¡distinguiendo por nombre de host! (Me preguntaba lo mismo el otro día) :)

@alexeymuranov ¿cómo se determina si la contraseña ingresada por el usuario es la contraseña de cifrado para un directorio cifrado o la contraseña MAC para verificar la autenticidad de un directorio no cifrado? más --switches ? Se vuelve muy complicado muy rápido.

Me gustaría tener esta opción para realizar copias de seguridad locales. Por ejemplo, todos los días ejecuto una copia de seguridad de mi directorio ~ / Music en mi servidor, pero no necesito que esté encriptado. La copia de seguridad no es para proteger contra fallas o pérdidas de hardware (tengo otras copias de seguridad para eso), sino simplemente para proteger contra accidentes y bitrot. Y el servidor tiene una potencia bastante baja, por lo que la sobrecarga de cifrado es un problema.

@alphapapa para eso hay rsync .
EDITAR: Y permisos / atributos de archivos. Por cierto, ¿cuál es la diferencia entre "falla de hardware" y "bitrot"?

@cfcs , rsync no se deduplica.

para eso hay rsync.

@cfcs Como todos sabemos, un espejo no es una copia de seguridad. ;) Usando Obnam, mantengo una serie de copias de seguridad, similares a restic: keep = 7d,8w,12m,3y Desde que casi pierdo mi clave GPG (porque se truncó misteriosamente a 0 bytes sin que me diera cuenta, y se hizo una copia de seguridad del archivo truncado repetidamente), y tuve que sacarlo de una copia de seguridad de hace años en un CD-R, reconozco la importancia de mantener los datos de copia de seguridad antiguos.

Por cierto, ¿cuál es la diferencia entre "falla de hardware" y "bitrot"?

Bitrot generalmente pasa desapercibido hasta que necesita los datos corruptos y no hace que todo el dispositivo sea ilegible. La falla de hardware es, por ejemplo, que el disco falla por completo, el sistema no se inicia, etc.

Y como señala Alexey, rsync no deduplica, ni permite la eliminación de datos de respaldo antiguos, ni verificaciones de integridad de datos, etc. rsync es una herramienta excelente y la uso con regularidad, pero no para hacer respaldos .

El cifrado ya no es caro, al menos no si tiene AES-NI (cifrado acelerado por hardware), que es bastante común hoy en día (al menos en computadoras portátiles y servidores)

A menos que su software esté escrito en go. Crypro de Go es un software solo para cualquier cosa, excepto para Intel, por lo que con un dispositivo Arm está atascado con el "tiempo de respaldo estimado: 14 días" para el mismo conjunto de archivos que se completa en menos de 30 minutos con la solución de respaldo oficial basada en openssl en mi NAS .

También me gustaría ver esta función. Estoy usando SSH para la transferencia y estoy almacenando mis copias de seguridad en volúmenes cifrados LUKS / cryptsetup, por lo que el cifrado solo agrega el riesgo de perder la clave de cifrado. Además, el cifrado agrega más propensión a errores y agrega una carga innecesaria a la CPU.

Sin embargo, el cifrado es muy útil cuando estoy haciendo una copia de seguridad en un objetivo que no es de confianza.

Las personas pueden estar motivadas para proteger un archivo de texto que incluya la contraseña junto con la copia de seguridad ...

También utilizo un objetivo de copia de seguridad cifrado luks / dm-crypt. Es un disco USB externo que monte en / Backup /
Puede simplemente crear un archivo de contraseña en esa ubicación (/ Backup / restic_password) y alimentarlo a restic usando --password-file. El repositorio se encuentra en / Backup / restic_repo /
Es importante hacer que el archivo de contraseña sea inmutable, o se arruinará si se pierde por accidente: chattr + i / Backup / restic_password
También utilizo "restic" como contraseña, por si acaso.

La función de cifrado de Restic es muy útil si realiza copias de seguridad en objetivos que no son de confianza, como proveedores en la nube. Pero si solo usa unidades externas que almacena en casa, o un NAS en su sótano, entonces el cifrado forzado es un poco loco. El usuario medio olvidará la contraseña de todos modos.

Permitir copias de seguridad no cifradas permitiría a ZFS, BtrFS o NTFS o cualquier sistema de archivos comprimir las copias de seguridad.

(El cifrado se puede realizar a través de dmcrypt en una capa inferior si se desea)

Permitir copias de seguridad no cifradas permitiría a ZFS, BtrFS o NTFS o cualquier sistema de archivos comprimir las copias de seguridad.

Lo mismo aquí, sin compresión y el cifrado obligatorio ocupa demasiado espacio en mi servidor de respaldo. Mi caso de uso (algunas imágenes, muchos archivos pequeños xml / txt / csv) se beneficiaría enormemente sin cifrado (por lo que ZFS podría hacer lo suyo) o compresión (relación de compresión ~ 2.3 con zstd, 5).

Si está utilizando ZFS, ¿por qué no utilizar instantáneas zfs send ?

Las instantáneas de ZFS no son suficientes para realizar copias de seguridad en muchos casos. Si tiene daños no detectados en un archivo, o si desea tener conjuntos guardados para años, las instantáneas de ZFS no ayudan mucho. Digamos que está utilizando FreeNAS y desea mantener un año de copias de seguridad semanales. La programación y la administración de instantáneas integradas en FreeNAS no son _realmente_ suficientes para lograrlo correctamente. No es "empresarial".

Si tiene un sistema de programación más elaborado, probablemente funcionaría mucho mejor. También existe el problema del envío de zfs que requiere que exista una instantánea antes de poder enviarlo; también tiene que administrar una programación de instantáneas y asegurarse de que su instantánea y el envío programado estén sincronizados (manualmente) para que alcance su RTO / RPO.

Y sí ... estoy hablando de funciones empresariales en FreeNAS. Pero esa es la preocupación ...

El cifrado ya no es caro, al menos no si tiene AES-NI

El requisito de AES-NI excluye muchos servidores más antiguos (¡que en algunos casos es _especialmente importante_ respaldar!).

Estoy ayudando a alguien a obtener mejores copias de seguridad que se ejecutan en una colección de servidores en las zonas rurales de África, en hardware donado de más de 10 años (¡algunos de ellos incluso son de 32 bits!). Me temo que el cifrado simplemente agregará demasiada sobrecarga, así que supongo que por ahora tendré que buscar en otra parte.

+1 para sin cifrado

esto sería útil

+1 para sin cifrado

esto sería útil

Utilice la función de pulgar hacia arriba en el problema original en lugar de "+1" para evitar inundar las bandejas de entrada de los espectadores. ¡Gracias!

¿Cuál es el estado de esta función?

Necesito hacer una copia de seguridad de los archivos (documentos compartidos como traducciones de manuales de usuario) desde el servidor interno de samba al que todos los usuarios de la empresa tienen acceso de todos modos, no son realmente confidenciales dentro de los límites de la empresa. El cifrado de copia de seguridad en este caso no tiene sentido, de todos modos estoy usando jailkit para seguridad adicional para las copias de seguridad, y uso el sistema de archivos btrfs con la compresión habilitada. De todos modos, hago copias de seguridad de cosas como volcados de discos de máquinas virtuales de otras maneras. El cifrado no es un problema en mi caso de uso, prevenir la pérdida de datos es la única prioridad. Usar una contraseña como 'restic' es una solución tonta.

Implementa esto.

@mrkafk ¿Cuál es el problema real para usted con restic tener cifrado? Incluso si no lo necesita, necesitará razones muy específicas para que sea un problema, ya que es muy probable que sus CPU sean compatibles con el cifrado de hardware.

He descrito mi problema real: dado el contexto específico, no lo necesito, mientras que, según tengo entendido, al menos elimina las ganancias de compresión en el sistema de archivos btrfs. Tengo toneladas de archivos para respaldar, por eso estoy usando btrfs con la compresión habilitada en primer lugar porque con RAID-1 para la redundancia de hardware necesito mucho espacio en disco (si no fuera por eso, preferiría usar ext4). Además, encriptar con lo que equivale a una contraseña falsa y hacer encriptación innecesariamente se siente ... tonto.

De acuerdo, de las cosas que escribió, deduzco un problema real , a saber, que la compresión BTRFS no es tan efectiva como podría ser sin cifrado. Ese es un buen punto. Además de eso, no veo nada que te limite debido al cifrado de Restic.

Es imposible perder la clave de cifrado si no está cifrada. Eso es especialmente relevante para las copias de seguridad.

Mebus

Es imposible perder la clave de cifrado si no está cifrada. Eso es especialmente relevante para las copias de seguridad.

Eso se ha discutido como si el mundo se acabara mañana :) https://github.com/restic/restic/issues/1786