Tape 📼 Improvements – VBR v11 🔥

Cuando pensé que la cinta se había olvidado :gritar:… Veeam nos trae estas mejoras que creo que son excelentes! : nerd:

Tape 📼 Mejoras

:circulo rojo: Tape Cloning !!!

  • Nos permite migrar de LTO antiguo a generaciones de cintas más nuevas
  • Copia adicional por razones de seguridad
  • Puede copiar de un drive a otra a través del Tape Server
  • Puede modificar la base de datos y vincular Backups antiguos con Tapes nuevos
  • Puede conservar el enlace para Tapes antiguos
  • Las partes del archivo se detectan y solicitan Tape adicional

: mano_alzada: Nota:

Veeam puede clonar todas las cintas de Veeam (B2T, F2T, NDMP), Veeam no puede hacerlo para cintas de terceros.

: diamantes: Lo que necesitas saber : escribiendo_mano:

  • Requiere al menos dos Drives
  • Si existen varias copias, Restore selecciona automáticamente la cintas necesarias
  • Sin Scheduler (use PowerShell)
  • Un Media Pool solo permite una generación LTO

Veeam Backup & Replication v11 🤓 New Linux🐧 Backup Proxy Modes

Linux Backup Proxy Mejorados

Los clientes buscan utilizar más Linux !

Antes solo podíamos utilizar el modo de transporte HotAdd

Las mejoras son en modos de transporte son:

  • Network Mode (NBD)
  • Direct SAN (NFS,iSCSI and FC)
  • Backup from storage snapshot (iSCSI, FC)

📌 Nos quedaría el siguiente escenario

🐧 Las Mejoras de HotAdd

  • Soporte de lectura Asincrónica
  • Los mismo que se hacemos para Windows con la “Busqueda de datos avanzada”

Limitaciones

  • No soporta snapshot storage para NFS
  • No soporta Veeam Agent para WINDOWS backup from Storage snapshots

Espero que este Post los tenga contando los días para la nueva v11 de Veeam !!

VBR v11 🔥 Como trabaja CDP con Retention Policies

CDP – Retention Policies Una política de retención define durante cuánto tiempo Veeam Backup & Replication debe almacenar los puntos de restauración para las réplicas de VM. Veeam Backup & Replication ofrece dos esquemas de políticas de retención: Retención a largo plazo Retención a corto plazo Retención a largo plazo Veeam Backup & Replication conserva … Sigue leyendo VBR v11 🔥 Como trabaja CDP con Retention Policies

Overview Veeam Legends 🦁

Hoy tengo la felicidad que me han elegido para el programa de Veeam Legends, una gran forma de compartir ideas, dudas, y conocimiento tecnico de Veeam. Un honor seguir contribuyendo desde las dos comunidades Veeam Legends y Veeam Vanguard !! Les doy una descripción general del programa. Quiénes son Veeam Legends? Veeam Legends son usuarios … Sigue leyendo Overview Veeam Legends 🦁

vSphere with Tanzu: Kubernetes de Alta Disponibilidad 🕹️

vSphere con alta disponibilidad de Tanzu 🤓 Comencemos analizando genéricamente las soluciones de nube pública, ya que ofrecen una plantilla para proporcionar infraestructura y aislamiento de servicios críticos. Los recursos de la nube pública se alojan en regiones geográficas segmentadas en zonas de disponibilidad (AZ) que proporcionan un conjunto de servicios e infraestructura física aislados. … Sigue leyendo vSphere with Tanzu: Kubernetes de Alta Disponibilidad 🕹️

Veeam Backup Repository Design 🔥

En este tema veremos sobre el diseño del repositorio.

Necesitamos considerar 

  • La recomendación clave es seguir la  regla 3 -2-1 .
  • Calcule 1 núcleo y 4 GB de RAM por repository task slot. El mínimo recomendado para un repositorio es de 2 núcleos y 8 GB de RAM.

Dimensionamiento  : nerd:

  • La cantidad recomendada de CPU para un repositorio es de 1 núcleo por ranura de tarea configurada concurrente en un servidor de repositorio. Configure como mínimo un servidor de repositorio de 2 núcleos y 8 GB de RAM para permitir que el sistema operativo responda mejor.
  • Al dimensionar los espacios de tareas en un repositorio, debe comprender cuándo y cuántos espacios de tareas se consumen. Cualquier proceso de escritura consumirá un espacio de tarea. Por lo tanto, hacer una copia de seguridad de 10 máquinas virtuales en un trabajo utilizando cadenas de copia de seguridad por trabajo solo escribirá un archivo (VBK / VIB) al final, por lo que consume una ranura de tarea.
  • Ejecutar el mismo trabajo de respaldo con archivos de respaldo por VM creará un archivo por VM y, por lo tanto, puede aprovechar hasta 10 ranuras de tareas (cuando estén disponibles).
  • Los trabajos de copia de respaldo, los respaldos de agentes y los trabajos de complementos también consumen espacios de tareas y deben tenerse en cuenta.
:chincheta:

Una tarea en el nivel de repositorio se consume de manera diferente que las tareas en el nivel de proxy. Si los “archivos de respaldo por VM” están  habilitados  en el repositorio, cada VM procesada simultáneamente consumirá una tarea de repositorio, mientras que cada disco virtual de esta VM consumirá una tarea de proxy (la proporción típica es de 3 discos por VM)

:chincheta:

Si los “archivos de copia de seguridad por máquina virtual” están  deshabilitados , una sola tarea de copia de seguridad consumirá solo una tarea de repositorio, independientemente de la cantidad de máquinas virtuales que esté procesando la tarea. Pero la cantidad de tareas de proxy consumidas seguirá siendo la misma (una tarea por cada disco virtual).

Ejemplo :guiño:

Si el requisito principal para el proxy es 16 núcleos para el incremental, los núcleos para el repositorio serán 5 según una proporción de disco a máquina virtual de 3: 1(redondeado). Para calcular la RAM, esto se multiplica por el requisito de RAM de 4 GB por núcleo, lo que da como resultado 20 GB.

Cuando el resultado de su cálculo sea un servidor (virtual) muy pequeño, considere recursos adicionales para la sobrecarga del sistema operativo (1 Core / 4GB RAM adicional debería ser suficiente). Normalmente, los tamaños tienden a ser de un mínimo de 4 núcleos / 16 GB para servidores virtuales o servidores físicos con> 10 núcleos y 64 GB de RAM donde de todos modos hay suficientes recursos disponibles para el sistema operativo.

¿Qué pasa con ReFS? :pensando:

Al usar el sistema de archivos Windows ReFS, la recomendación es agregar 0.5 GB de RAM por TB de almacenamiento ReFS. Sin embargo, no tiene que escalar esto indefinidamente. 128 GB de RAM suelen ser suficientes para los requisitos de tareas, SO y ReFS si el tamaño total del volumen de ReFS del servidor es inferior a ~ 200 TB. Según el tamaño de ReFS o los requisitos de la tarea, es posible que desee agregar más memoria, pero no debería ser necesario superar los 256 GB.

: point_right: Espero te sea de utilidad