Linux Snapshots: how-to y dudas...

unreal4u · 8 Septiembre 2023

Veníamos comentando acerca de respaldos en otro thread ( https://www.capa9.net/goto/post?id=14017491 ) y me surgieron algunas dudas. No quise ensuciar ese thread con contenido demasiado técnico, así que creé un thread nuevo jajajaj

Resumen:

Tengo contratado Google One de 2TB, me sale €10 al mes.
Tengo una colección grandota de fotos de forma local (según Google, por lo bajo 340GB).
Quiero alojarlos de forma local, con immich
Pero quiero respaldar esto a la nube, utilizando GCS en modo archive

El modo archive es ideal para guardar recursos que estarán ahí mucho tiempo, pero tiene costos asociados a retrieval de archivos: así que un rsync queda descartado pq básicamente hará millones de transacciones tipo A y B.

Peeero... @Cosme tiró la idea de mejor tirar los snapshots al archive! Creo que me gusta la idea ya que en vez de tener que pasar por millones de fotos, el snapshot serían un par de archivos.

Pero tengo algunas dudas ya que nunca he hecho este tipo de respaldos:

Qué me recomiendan? BTRFS o ZFS? Personalmente iría por BTRFS pq es más nuevo, pero puede que uds tengan más experiencia así que estoy abierto a sugerencias
Me imagino que esto crea un archivo que subiría a GCS. Al día siguiente creo uno incremental? Significa que si mi colección es de 500GB, el snapshot será de 500GB tb? O sea que mi disco de 1TB se llenaría bastante rápido.
Cuánto historial necesitaría? En archive pago un año de espacio sí o sí, aunque yo no pretendo borrar nunca. Cuando necesite recuperar el snapshot, tendría que bajar toooodo el historial de snapshots? O bien, después de un año puedo crear uno de cero y empezar de nuevo? Qué recomiendan?

Saludos.

galansinchance · 16 Octubre 2023

Qué es lo que estás buscando en la elección del sistema de archivos, para el uso que le he dado a los equipos no he encontrado grandes diferencias entre EXT4 y ZFS, pero BTRFS nunca lo he probado.

Si es snapshot, has probado AWS Glacier?

cliobrando · 16 Octubre 2023

En el caso de ZFS para que funcionen snapshots incrementales al otro lado debe existir también un filesystem ZFS, no tengo mucha experiencia con BTRFS pero me imagino que debe ser similar.
Una vez le pregunté a un representante de amazon cuál era la mejor forma de guardar fotos y me dijo: en un álbum físico.

unreal4u · 16 Octubre 2023

Uh se me había olvidado este thread 😅

Al final probé el sistema de snapshots de BTRFS, pero lo encontré bastante complicado de usar sobretodo cuando uno tiene que considerar un backup remoto (el equipo que tengo no le da para hacer un RAID / meterle más de 2 discos ya que tiene una conexión SATA y otra NVME), así que al final me decidí por una solución "keep it simple stupid".

Así que hice lo mismo que ya hacemos en la pega: hacer un sistema de respaldos con restic y BackBlaze en vez de GCP o Amazon: si bien es cierto es más lento, para lo que yo necesito funciona bien (la latencia es tema en B2 si tienes que hacer egress de >10TB de archivos chicos al día, cosa que yo no haré ni necesito) y no tienen costos por egress ni tampoco por la cantidad de transacciones que uno hace. Lo ocupamos tb para la pega para respaldar cerca de 50 teras de información como nube secundaria así que ya tenía todas las herramientas. Mientras mi librería no crezca en el orden de varios TBs no tendré los problemas que sí tuvimos en la pega en cuanto a recursos, tiempos de ejecución, bloqueos y cache ya que serán ínfimos usos comparados con lo que ya tuve que pasar.

Por qué B2? Lo bueno es que lo único que uno paga son los GBs que uno tiene almacenado, (se paga por cada unidad de GB, a USD0.005 por GB), estoy ocupando ya un poco más de 550GB así que estimo que me saldrá cerca de USD2.6 al mes: 4 veces menos que Google Drive y aunque es un poco más caro que GCP modo archive, no me servía para esto por la retención mínima de 365 días + cobro excesivo de transacciones tipo A y B en este modo.

El script que escribí que realiza todo el proceso de respaldo:

Código:

#!/bin/bash

export B2_ACCOUNT_ID="xxx"
export B2_ACCOUNT_KEY="yyy"
export RESTIC_PASSWORD="zzz"

echo "Changing to current directory"
originalDir="$(realpath $(dirname "$0"))"
# First create a database backup
cd "${originalDir}/../"
echo "Creating new Immich PostGreSQL backup..."
/usr/bin/docker exec -t immich_postgres pg_dumpall -c -U postgres | gzip > immich-data/uploads/database-backups/dump-$(date +"%Y-%m-%d")_$(date +"%H-%M").sql.gz
echo "Deleting old database backups (+4)"
ls -tp immich-data/uploads/database-backups/dump-* | grep -v '/$' | tail -n +6 | xargs -I {} rm -- {}
cd "${originalDir}"

inputFile="directories-to-backup.txt"
while read -r directory
do
    echo "Unlocking ${directory}"
    # Ensure no locks are currently in place
    /usr/bin/restic unlock -r b2:aaaa:${directory}

    echo "Performing backup of ${directory}"
    # Perform the actual backup
    /usr/bin/restic backup --json=true --quiet -r b2:aaaa:${directory} --tag "photos" --tag "date-$(date +"%Y-%m-%d")" --tag "hour-$(date +"%H-%M")" ../${directory}/ > ./logs/summary_$(date +"%Y-%m-%d").json
    echo "Cleaning up old backups of ${directory}"
    if (( $(date +"%u") == 7 )); then
        # Clean up older backups we don't longer need, but only do the hard prune on Sunday
        /usr/bin/restic forget --keep-last 4 -r b2:aaaa:${directory} --prune
    else
        /usr/bin/restic forget --keep-last 4 -r b2:aaaa:${directory}
    fi
done < "$inputFile"

echo "All work done, cleaning up environment variables"
# Clean up our mess: unset all set environment variables
unset B2_ACCOUNT_ID
unset B2_ACCOUNT_KEY
unset RESTIC_PASSWORD

Esto corre una vez cada 24hrs, más que suficiente en este caso.

Así que eso... en este caso, snapshots no era la manera. Como son pocos datos, me salía mucho más rápido y simple utilizar herramientas y soluciones que están escritas específicamente para este use-case.

Saludos.

Linux Snapshots: how-to y dudas...

unreal4u

I solve problems.

galansinchance

enajenao

cliobrando

Capo

unreal4u

I solve problems.