Backup

Hay que tener en cuentas varios factores, a nivel de costes especialmente, para realizar backups y restaurar dichas copias entre aplicaciones incluso.

Los siguientes son diferencias de features que tiene la generación de backups manuales y programados:

Manual Scheduled
Can disable/enable writings CANNOT disable/enable writings
Can select which entities to copy HAVE to specify the entities to copy
has to pay for backup process have to pay backup process, network interaction and cron

CLoud Storage pricing

No hay cargos por uso de ancho de banda. Pero si por operaciones (https://cloud.google.com/storage/pricing#operations-pricing), y por URL fetch si se utiliza procesos que interactúan remotamente con Cloud Storage.

Tiene una capacidad de storage gratis de al menos:

Regional storage =5GB (gibibyte 2^30bytes)

Class A Operations =5,000

Class B Operations =50,000

Network Egress=1 GB from North America to each GCP egress destination (Australia and China excluded)

Mas información se puede encontrar enhttps://cloud.google.com/appengine/quotas?hl=es#Default_Gcs_Bucket.

Proceso de backup restore

(https://cloud.google.com/appengine/docs/standard/python/console/datastore-backing-up-restoring#backup_and_restore_considerations)

"Restores do not assign new IDs to entities. Restores use the IDs that existed at backup-time and overwrite any existing entity with the same ID. During a restore, the IDs are reserved as the entities are being restored. This should prevent ID collisions with new entities if writes are enabled while a restore is running. New entities added since the backup are retained."

Backup restore en otra aplicación

(https://cloud.google.com/appengine/docs/standard/python/console/datastore-backing-up-restoring#restoring_data_to_another_app)

Hay que agregar permisos de acceso al bucket creado para la otra aplicación

https://cloud.google.com/storage/docs/access-control/using-iam-permissions#bucket-add

El cambio de permisos en un bucket no afectan a backups realizados previamente. La aplicación "objetivo" solo puede acceder backups hechos después de que se le dieron permisos.

Set up de bucket y configuración de acceso

  1. entrar a la consola del proyecto propietario del bucket

  2. ir a Storage/navegador

  3. Seleccionar un bucket, e ir a "editar permisos de segmento"

  4. Agregar miembros, escribir el grupo y el id del proyecto que va a tener permisos de lectura en los buckets: "[email protected]"

  5. Agregar los siguientes permisos: "Lector de depósito heredados de almacenamiento" y "Lector de objetos de almacenamientos"

Realizar Backup

Para realizar un traspaso de datos desde una aplicación a otra los pasos a seguir son los siguientes:

  1. Entrar a la página de administración de Datastore

  2. Seleccionar las entities a backupear y seleccionar “Backup entities”

  3. agregar al nombre del bucket un string de form “_(nro de backup del día)”

  4. Settear como Google Cloud Storage bucket name: business-in-a-box{discriminador_de_ambiente_empezado_por-}.appspot.com/backups

  5. Seleccionar “Backup Entities”

Migrar datos entre aplicaciones

Para realizar un traspaso de datos desde una aplicación a otra los pasos a seguir son los siguientes:

  1. Copiar el bucket id del proyecto propietario del bucket.

  2. Entrar al panel del proyecto que quiere agregar lo contenido en el bucket. [previo a esto el proyecto debería al menos tener creada la entidad de almacenamiento en la región adecuada, y habilitado el administrador de datastore]

  3. Abrir el administrador de data store e ingresar el nombre del bucket a leer del proyecto origen (algo de forma business-in-a-box{discriminador_de_ambiente_empezado_por-}.appspot.com/backups)

  4. Una vez que se indican los imports, los backups se muestran ordenados en forma descendente.

  5. De ahí en adelante el proceso es o agregarlo a los backups que quedan disponibles y de ahí ejecutar un restore cada vez que sea necesario, o directamente ejecutar el restore

Instalando el CLI de Firebase

El host tiene que tener instalado node.js

Los pasos necesarios para instalar el CLI son:

  1. npm install -g firebase-tools

  2. firebase list

  3. mkdir firebase

  4. cd firebase

  5. firebase init

  6. (Select database)

  7. (select business-in-a-box-dev)

Exporting/importing firebase

Los datos que se utilizan para la importación son los requeridos a la gente de soporte de Firebase.

  1. firebase use business-in-a-box-dev

  2. firebase auth:export ../exported_auth.json

  3. firebase use business-in-a-box

  4. firebase auth:import ../exported_auth.json --hash-algo=BCRYPT

  5. firebase auth:import ../exported_auth.json --hash-algo=SCRYPT --hash-key=<<hashKey>> --salt-separator=Bw== --rounds=8 --mem-cost=14

Los datos para configurar el comando de import se deben extraer dehttps://docs.google.com/document/d/16HgfJqaS7XcaHCKpagj0yQ5JQ_2RO0DUU09_N01tV4g/edit. Notar que los datos a utilizar son los correspondientes al ambiente DESDE el que se hizo el backup.

Consideraciones con respecto a la exportación/importación de datos de autenticación

Con respecto a la forma en la que se exportan los datos de autenticación, se puede leer enhttps://firebase.google.com/docs/cli/auth#authexport: “Note: theauth:exportcommand only exports passwords hashed using the scrypt algorithm, which is used by the Firebase backend. Account records with passwords hashed using other algorithms are exported with emptypasswordHashandsaltfields. Projects might have passwords hashed with other algorithms after importing user records from a file, since passwords are only re-hashed with scrypt when an imported user signs in for the first time.”

Con lo referido al id de los datos de autenticación del usuario, se puede leer enhttps://firebase.google.com/docs/cli/auth#file_format: “This ID should be unique among all accounts in your Firebase projects. If you import an account with a UID that already exists, the account will be overwritten.”

results matching ""

    No results matching ""