[{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/categories/compliance/","section":"Categorías","summary":"","title":"Compliance","type":"categories"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/coveware/","section":"Etiquetas","summary":"","title":"Coveware","type":"tags"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/dspm/","section":"Etiquetas","summary":"","title":"DSPM","type":"tags"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/gdpr-comparativa/","section":"Etiquetas","summary":"","title":"GDPR-Comparativa","type":"tags"},{"content":"","date":"7 mayo 2026","externalUrl":null,"permalink":"/en/tags/gdpr-comparison/","section":"Tags","summary":"","title":"GDPR-Comparison","type":"tags"},{"content":"","date":"7 mayo 2026","externalUrl":null,"permalink":"/en/tags/law-21719/","section":"Tags","summary":"","title":"Law-21719","type":"tags"},{"content":"Hoy en día, la protección de datos personales dejó de ser una conversación que vive solo en el área legal. Con la entrada en vigencia de la Ley 21.719 el 1 de diciembre de 2026, las áreas de IT se convierten en un actor crítico del cumplimiento, y los planes de respaldo, recuperación y respuesta a incidentes pasan a ser evidencia auditable frente a la nueva Agencia de Protección de Datos Personales. Las sanciones, que pueden llegar a las UTM 20.000 o al 4% de los ingresos anuales por ventas y servicios en Chile (alrededor de $1.392 millones de pesos chilenos en su tope UTM, y hasta tres veces ese monto por reincidencia), nos obligan a traducir cada principio de la ley a un control técnico concreto, no a una declaración de buenas intenciones.\nDe la ley al control técnico al stack: cada principio se mapea a un componente concreto. Nota importante: Este post es una interpretación técnica desde el rol de Solutions Architect Nerd, no constituye asesoría legal. El análisis legal definitivo de cualquier organización debe realizarse en conjunto con sus equipos jurídicos y, según corresponda, con asesoría externa especializada en protección de datos personales.\nIntroducción # En Chile, la antigua Ley 19.628 sobre protección de la vida privada quedó por más de dos décadas sin una autoridad de control real, sin sanciones efectivas y sin obligaciones técnicas claramente definidas para las organizaciones que tratan datos personales. Esto cambia de forma profunda con la promulgación de la Ley 21.719, publicada el 13 de diciembre de 2024, que entra en plena vigencia el 1 de diciembre de 2026.\nLa nueva ley nos lleva al estándar GDPR europeo en términos de derechos del titular, obligaciones del responsable del tratamiento, sanciones y, sobre todo, la creación de una Agencia de Protección de Datos Personales con potestades fiscalizadoras y sancionatorias reales. Para las áreas de IT, esto significa que los controles técnicos sobre los datos personales pasan a ser objeto de auditoría externa, y que la documentación que respalda cada control se convierte en evidencia que puede ser requerida en un proceso de fiscalización.\nEn este contexto, la Plataforma de Veeam es un componente clave para implementar y evidenciar varios de los principios establecidos por la ley, en particular los relacionados con confidencialidad, integridad y disponibilidad de los datos personales. En este post, veremos cómo se mapea cada principio con capacidades concretas de Veeam Backup \u0026amp; Replication, Veeam ONE y el resto del stack, con el objetivo de entregar una matriz auditable que puedas llevar directamente al sistema de gestión documental de tu organización.\nLo que cambia con la Ley 21.719 frente a la Ley 19.628 # Antes de bajar a controles técnicos, es importante entender qué es lo realmente nuevo. La diferencia entre ambos cuerpos legales no es de redacción, es de paradigma.\nCreación de la Agencia de Protección de Datos Personales # La Agencia es el nuevo organismo autónomo encargado de fiscalizar el cumplimiento de la ley, recibir denuncias, instruir procedimientos sancionatorios y emitir instrucciones generales y particulares. A diferencia del modelo anterior, donde el titular debía recurrir a tribunales civiles para ejercer sus derechos, ahora existe una vía administrativa especializada y, lo más relevante para IT, una autoridad técnica que puede solicitar evidencia documental sobre las medidas de seguridad implementadas.\nSanciones graduadas con efecto disuasivo real # Las sanciones se clasifican en tres niveles, con un piso desde 1 UTM y los topes que se detallan a continuación (referencia: UTM ~$69.611 CLP a febrero 2026):\nInfracciones leves (Art. 34 bis): hasta UTM 5.000, aproximadamente $348 millones de pesos chilenos (~USD 305 mil).\nInfracciones graves (Art. 34 ter): hasta UTM 10.000 o, alternativamente, hasta el 2% de los ingresos anuales por ventas y servicios en Chile para empresas que no califiquen como PyME (lo que resulte mayor entre ambos cálculos). El tope UTM equivale aproximadamente a $696 millones de pesos chilenos (~USD 610 mil).\nInfracciones gravísimas (Art. 34 quáter): hasta UTM 20.000 o, alternativamente, hasta el 4% de los ingresos anuales por ventas y servicios en Chile para empresas que no califiquen como PyME (lo que resulte mayor entre ambos cálculos). El tope UTM equivale aproximadamente a $1.392 millones de pesos chilenos (~USD 1,2 millones), además de la posibilidad de suspensión de las operaciones de tratamiento.\nReincidencia: las multas pueden triplicarse cuando se acreditan infracciones graves o gravísimas reiteradas, alcanzando hasta UTM 60.000 (~USD 3,6 millones).\nRégimen especial para PyMES (período de adaptación): durante el primer año de vigencia plena de la ley (1 de diciembre de 2026 al 1 de diciembre de 2027), las pequeñas y medianas empresas están sujetas únicamente a amonestación escrita por sus infracciones, no a multa. Este es un margen de adaptación significativo para el segmento PyME chileno, pero no exime del trabajo de implementación previo: la Agencia comenzará a documentar los incumplimientos desde el día uno, y al cierre del período de gracia esos antecedentes pasan a ser parte del historial de la empresa.\nLa omisión de medidas de seguridad razonables, la transferencia internacional sin garantías adecuadas y la falta de notificación oportuna de una brecha caen, todas ellas, dentro del rango de infracción grave o gravísima.\nObligación de Delegado de Protección de Datos (DPO) # Las organizaciones que realizan tratamiento masivo de datos personales o tratamiento habitual de datos sensibles deben designar un Delegado de Protección de Datos. Si bien el rol es típicamente liderado por el área legal o de cumplimiento, el DPO requiere apoyo técnico permanente del área de IT para validar que los controles declarados en el Registro de Actividades de Tratamiento (RAT) coinciden con la realidad operacional.\nEvaluaciones de impacto (DPIA) para tratamientos de alto riesgo # Antes de iniciar un tratamiento que pueda generar un alto riesgo para los derechos de los titulares, por ejemplo, decisiones automatizadas, perfilamiento, tratamiento masivo de datos sensibles o videovigilancia a gran escala, la organización debe realizar una Evaluación de Impacto. Este punto tiene una implicancia técnica directa: toda nueva arquitectura de respaldo o replicación que involucre datos sensibles o transferencia internacional debe pasar por una DPIA documentada antes de implementarse.\nNotificación obligatoria de brechas en 72 horas # El Art. 14 sexies establece que cuando se detecta una brecha de seguridad que afecta datos personales, el responsable debe notificar a la Agencia en un plazo máximo de 72 horas desde el conocimiento de la brecha. Y según la gravedad, también debe notificar a los titulares afectados. Este punto es el que más presión técnica genera, porque obliga a las organizaciones a tener capacidad real de detección, contención y comunicación dentro de un plazo muy acotado.\nCómo se compara con GDPR: lo que ya tenemos avanzado y lo que necesita ajuste # Para las organizaciones que ya operan bajo GDPR, típicamente porque tienen filiales en Europa, clientes europeos o porque adoptaron el estándar de forma voluntaria, la buena noticia es que gran parte del trabajo técnico ya está hecho. La Ley 21.719 toma el modelo GDPR como referencia y replica casi todos sus principios, derechos y obligaciones. Lo que cambia es el detalle, la jurisdicción y, en algunos casos, los plazos.\nLo que se mantiene casi idéntico # Principios del tratamiento: licitud, lealtad, transparencia, finalidad específica, minimización, exactitud, limitación del plazo de conservación, integridad y confidencialidad, y responsabilidad demostrable. Los siete principios calzan uno a uno.\nDerechos del titular: acceso, rectificación, supresión (olvido), oposición, portabilidad y limitación del tratamiento. Se mantienen prácticamente sin modificaciones.\nDPIA y DPO para tratamientos de alto riesgo y para organizaciones que tratan datos masivos o sensibles.\nNotificación de brechas en 72 horas desde el conocimiento del evento.\nMecanismos de transferencia internacional: cláusulas tipo, BCR, países con nivel adecuado, consentimiento del titular en casos puntuales.\nRégimen de responsable y encargado del tratamiento con obligaciones contractuales mínimas establecidas.\nDiferencias relevantes que sí debemos ajustar # Sanciones: GDPR llega hasta el 4% de la facturación anual global o EUR 20 millones (el mayor de los dos). Ley 21.719 llega hasta UTM 20.000 (~USD 1,2 millones) o el 4% de los ingresos anuales por ventas y servicios en Chile (lo que resulte mayor para empresas no PyME), con triplicado por reincidencia hasta UTM 60.000. La estructura es muy similar al esquema GDPR, con la diferencia que el cálculo de revenue chileno se acota a operaciones en Chile, no global.\nAplicación territorial: GDPR tiene aplicación extraterritorial, aplica a cualquier organización que trate datos de residentes en la UE, sin importar dónde esté establecida. Ley 21.719 tiene un alcance más acotado al tratamiento que ocurre en Chile o que afecta a residentes chilenos, sin la misma extensión extraterritorial automática.\nJurisprudencia y guía oficial: GDPR cuenta con varios años de jurisprudencia europea, decisiones de autoridades nacionales y, sobre todo, guías del European Data Protection Board (EDPB) que aclaran zonas grises. La Ley 21.719 partirá con guías iniciales de la Agencia, pero la interpretación se construirá durante los primeros años de aplicación.\nDatos sensibles: ambas leyes consideran categorías especiales (salud, biométricos, origen étnico, opiniones políticas, etc.), pero las definiciones específicas tienen matices, particularmente en el tratamiento por órganos del Estado y en las excepciones aplicables.\nRégimen para el sector público: la Ley 21.719 establece un régimen específico para órganos del Estado, con matices en consentimiento, finalidades y bases de licitud que difieren del modelo GDPR.\nImplicancia práctica para IT # Si tu organización ya cumple GDPR, los controles técnicos del stack, encryption con KMS, inmutabilidad, RBAC, retention justificada, runbook de respuesta a brechas, RAT, se reutilizan prácticamente en su totalidad. Lo que cambia es la documentación, los contratos con proveedores cloud y el interlocutor regulatorio. La matriz auditable que entregamos a la Agencia chilena se puede construir a partir de la documentación que ya existe para GDPR, ajustando referencias normativas y al nuevo organismo. En términos prácticos, el stack Veeam que cumple GDPR cumple Ley 21.719, y el esfuerzo restante es de tipo legal-administrativo más que técnico.\nPor qué los respaldos pasan de ser un tema operativo a ser un tema legal # Existe una idea instalada en muchas organizaciones de que el respaldo es un tema puramente operacional, propiedad del área de infraestructura, y que su rol frente al regulador es secundario. Con la Ley 21.719 esto deja de ser cierto.\nEl principio de integridad y confidencialidad establecido en el Art. 3 de la ley, junto con el deber de seguridad de los artículos siguientes, nos obliga a proteger los datos personales contra pérdida, alteración o destrucción no autorizada, ya sea accidental o intencional. Una estrategia de respaldo y recuperación bien documentada deja de ser una buena práctica y se convierte en evidencia de cumplimiento. La ausencia de medidas razonables en este ámbito puede ser interpretada como una infracción grave o gravísima por omisión, especialmente si producto de un incidente de ransomware, falla de hardware o error humano se produce una pérdida de datos personales que era razonablemente prevenible.\nAdicionalmente, frente a una brecha o un incidente, la capacidad de recuperar datos desde un punto en el tiempo previo al evento es la diferencia entre informar a la Agencia \u0026ldquo;se perdieron los datos\u0026rdquo; y \u0026ldquo;los datos fueron recuperados sin pérdida\u0026rdquo;. La Plataforma de Veeam, con sus capacidades de inmutabilidad, recuperación granular y verificación automatizada, es la respuesta técnica frente a estos escenarios, manteniendo la integridad y disponibilidad de los datos protegidos.\nConfidencialidad: encryption end-to-end con Veeam y KMS externo # El primer principio que debemos atacar técnicamente es la confidencialidad. La ley exige que los datos personales estén protegidos contra accesos no autorizados, tanto en tránsito como en reposo, incluyendo todas sus copias de respaldo.\nCifrado en jobs de respaldo # Veeam Backup \u0026amp; Replication permite habilitar cifrado AES-256 a nivel de job, lo que significa que los datos quedan cifrados desde el momento del respaldo y permanecen cifrados en el repositorio de destino, incluyendo las copias replicadas a sitios remotos o capacity tiers en object storage. Es importante notar que el cifrado debe habilitarse en el job, no solo en el repositorio, porque el cifrado en el repositorio (cuando existe) protege únicamente contra acceso al storage, mientras que el cifrado en el job protege adicionalmente los datos en tránsito y los datos que viajan a las copias secundarias.\nIntegración con KMS externo # Una de las prácticas que más diferencia un cumplimiento sólido de uno superficial es la separación de responsabilidades en la gestión de llaves. Si la llave de cifrado vive en el mismo Veeam Backup Server que ejecuta el respaldo, entonces el operador del respaldo tiene acceso indirecto a los datos en claro, lo que viola el principio de mínimo privilegio.\nLa solución es integrar Veeam con un Key Management Service externo, opciones como:\nHashiCorp Vault: la opción para entornos Kubernetes protegidos con Veeam Kasten. Vault gestiona las llaves de cifrado y los secretos de las aplicaciones K8s cubiertas por el respaldo, integrándose nativamente con Kasten para el ciclo completo de backup, recovery y replicación cross-cluster.\nAWS KMS: cuando el repositorio principal o secundario reside en AWS, es la opción natural. Soporta CMK con políticas de IAM granulares.\nAzure Key Vault: análogo al anterior, para entornos Azure. Permite Hardware Security Module (HSM) en la opción Premium.\nGoogle Cloud KMS: para entornos GCP, con soporte CMEK y separación de proyectos.\nKMIP (Key Management Interoperability Protocol): estándar OASIS soportado de forma nativa por Veeam Backup \u0026amp; Replication. Permite integrarse con cualquier KMS empresarial compatible (Thales CipherTrust, Entrust KeyControl, Fortanix DSM, IBM Security Guardium, entre otros) sin atarse a un vendor cloud específico. Es la opción natural cuando la organización ya tiene una solución de gestión de llaves corporativa propia y prefiere mantenerse cloud-agnostic, o cuando los requerimientos de soberanía exigen que la llave nunca abandone la infraestructura del cliente.\nLo que hace esta integración es mover la llave fuera del Backup Server, de modo que para descifrar un respaldo se requiere autorización tanto del operador de Veeam como del custodio de la llave en el KMS, con audit log independiente. Es decir, ningún rol único tiene la capacidad de exfiltrar datos personales en claro.\nEvidencia auditable que entregamos # Frente a un proceso de fiscalización, los documentos que respaldan este control son:\nExport de la configuración del job mostrando que la opción de cifrado AES-256 está habilitada. Captura del audit log del KMS mostrando los eventos de uso de la llave (encrypt, decrypt, rotate). Procedimiento documentado de rotación periódica de llaves, con la frecuencia justificada según el análisis de riesgo de la organización. Procedimiento documentado de revocación de llaves ante eventos de compromiso, con tiempos objetivo (RTO específico para revocación). Integridad: Hardened Repository e inmutabilidad real, no la del marketing # El segundo principio que debemos abordar es la integridad. Aquí entra el componente más estratégico de toda arquitectura de respaldo moderna: la inmutabilidad.\nObject Lock en modo Compliance versus Governance # Cuando hablamos de inmutabilidad sobre object storage (S3, Azure Blob con Immutable Policies, Google Cloud Storage Bucket Lock), existen dos modos posibles:\nModo Governance: el objeto no se puede borrar, pero un usuario con privilegios elevados específicos (típicamente con permisos de \u0026ldquo;BypassGovernanceRetention\u0026rdquo; o equivalente) puede eliminar el lock y borrar el dato.\nModo Compliance: el objeto no se puede borrar por nadie hasta que expire la retention configurada. Ni siquiera el usuario root de la cuenta cloud puede saltarse este lock.\nLa diferencia entre ambos modos no es un detalle de implementación, es la diferencia entre que tu inmutabilidad sea válida frente a la ley o no. Bajo el principio de integridad y confidencialidad del Art. 3 de la Ley 21.719 y la obligación de adoptar medidas de seguridad razonables para impedir alteración o destrucción no autorizada de los datos, únicamente el modo Compliance es defendible como medida técnica suficiente, porque solo el modo Compliance garantiza que ni un atacante que comprometa credenciales privilegiadas, ni un insider con acceso administrativo, pueden borrar las copias de respaldo dentro del período de retención declarado.\nLinux Hardened Repository on-premise # Para los respaldos on-premise, Veeam ofrece la posibilidad de configurar un Linux Hardened Repository. Esta arquitectura combina varios controles:\nImmutable Filesystem flag: los archivos de respaldo se marcan con chattr +i, lo que impide su modificación o borrado a nivel de filesystem hasta que expire el período de inmutabilidad.\nSingle Use Credentials: el Backup Server se autentica al repositorio una sola vez para escribir el respaldo, y luego no almacena las credenciales SSH. Esto significa que si el Backup Server es comprometido, las credenciales del repositorio no quedan disponibles para el atacante.\nRepositorio fuera del dominio Active Directory: el servidor que actúa como Hardened Repository no debe estar joineado al dominio AD de producción, porque eso lo expondría a movimientos laterales basados en compromiso de credenciales de dominio.\nAislamiento del Backup Server # Adicionalmente al Hardened Repository, el propio Veeam Backup Server debe estar aislado del dominio AD principal, idealmente en un dominio dedicado o en grupo de trabajo, con MFA obligatorio en la consola y RBAC granular para que ningún operador tenga, simultáneamente, acceso a producción y acceso a la consola de respaldo.\nEvidencia auditable que entregamos # Configuración del repositorio mostrando que la inmutabilidad está habilitada en modo Compliance. Reporte de Veeam ONE que confirma el porcentaje de jobs con destino inmutable. Documentación de arquitectura mostrando el aislamiento de red y de identidad del Backup Server y del Hardened Repository. Test periódico de tentativa de borrado fallida, con timestamp, como prueba de que el lock funciona. Disponibilidad: la regla 3-2-1-1-0 traducida a evidencia auditable # El tercer principio es la disponibilidad. Aquí, la regla 3-2-1-1-0 que la industria ha adoptado se convierte directamente en una matriz de cumplimiento.\n3 copias de los datos. 2 medios distintos. 1 copia offsite. 1 copia offline o inmutable. 0 errores en la verificación. Cada copia, cada medio y cada verificación se documenta como anexo del Registro de Actividades de Tratamiento. La diferencia entre \u0026ldquo;creemos que el respaldo funciona\u0026rdquo; y \u0026ldquo;tenemos evidencia mensual de que el respaldo funciona\u0026rdquo; es lo que hace SureBackup. SureBackup ejecuta una verificación automatizada y aislada del respaldo: levanta una máquina virtual desde la copia, valida que el sistema operativo bootea, valida que servicios críticos (como SQL, Active Directory u Oracle) responden, y genera un reporte con el resultado.\nEl reporte de SureBackup, junto con los reportes mensuales de Veeam ONE sobre RPO y RTO efectivos, son los documentos que se anexan al Registro de Actividades de Tratamiento como evidencia formal del control de disponibilidad. Lo que el auditor va a pedir no es \u0026ldquo;muéstrame tu Backup Server\u0026rdquo;, es \u0026ldquo;muéstrame los doce reportes mensuales de verificación del último año\u0026rdquo;.\nDerecho al olvido sobre respaldos inmutables: la respuesta operacional con Veeam # Aquí está el punto que más confusión genera en las organizaciones, y que merece una sección dedicada porque la respuesta superficial es errada.\nEl Art. 7 de la ley establece el derecho de supresión del titular: cuando una persona ejerce su derecho al olvido sobre sus datos personales, porque ya no son necesarios para la finalidad del tratamiento, porque se revocó el consentimiento sin otra base legal, porque el tratamiento fue ilícito, o por orden judicial, la organización está obligada a eliminarlos en un plazo razonable. El problema es que los respaldos por definición están diseñados para no poder borrarse selectivamente. Si tengo un respaldo full de una base de datos del lunes pasado, no puedo \u0026ldquo;borrar la fila de Juan Pérez\u0026rdquo; sin invalidar el respaldo completo. Y si los respaldos son inmutables, el problema se duplica.\nLa respuesta primaria: Staged Restore + retention mínima + inmutabilidad + documentación # Para la inmensa mayoría de las organizaciones que protegen cargas tradicionales con Veeam (VMs, bases de datos, file shares, SaaS), la combinación que cumple defendiblemente con el derecho de supresión bajo Ley 21.719 es la siguiente:\nStaged Restore para asegurar que el estado productivo activo refleja la supresión del dato del titular. Este es el control efectivo y operacional, y es donde realmente se cumple con el derecho de olvido. Retention al mínimo legal aplicable, justificada documentalmente. Los respaldos históricos del titular existen, pero por un plazo acotado y demostrable en el Registro de Actividades de Tratamiento. Inmutabilidad sobre ese mismo respaldo histórico, demostrando que durante el plazo de retention nadie puede acceder ni modificar los datos del titular. Registro documental honesto que reconozca explícitamente: \u0026ldquo;los datos del titular fueron suprimidos del estado productivo el día X mediante Staged Restore; permanecen en respaldos históricos durante N meses por obligación legal Y; al expirar la retention serán eliminados automáticamente; durante el plazo no se realizan operaciones sobre esos respaldos\u0026rdquo;. Esta combinación es la respuesta defendible ante la Agencia, y es la que realmente aplica al setup típico de Veeam protegiendo cargas mixtas. La detallamos a fondo en la sección de Staged Restore que viene a continuación.\nStaged Restore: la respuesta operacional de Veeam para el derecho al olvido # Veeam Backup \u0026amp; Replication ofrece desde la versión 9.5 Update 4 una funcionalidad específicamente diseñada para flujos de derecho al olvido y obligaciones de borrado selectivo: Staged Restore.\nLo que hace Staged Restore es lo siguiente:\nRecuperación a un entorno aislado: la VM o el workload se restaura desde el respaldo inmutable hacia un entorno de pruebas o \u0026ldquo;lab\u0026rdquo; aislado de producción, sin exponerse en la red corporativa.\nEjecución de scripts de sanitización: antes de que la VM sea publicada en producción, Veeam ejecuta un script personalizado (PowerShell, Bash o el lenguaje que se requiera) que opera sobre los datos restaurados. Por ejemplo: eliminar registros de un titular específico de una base de datos, borrar archivos sensibles, anonimizar campos, aplicar transformaciones reversibles o irreversibles.\nPublicación del estado saneado: una vez que el script termina exitosamente, el workload saneado se publica en producción reemplazando el estado anterior.\nRegistro completo: cada Staged Restore queda registrado en el job log de Veeam con timestamp, script ejecutado, código de salida y duración, lo que sirve como evidencia operacional ante el regulador.\nEste flujo no modifica el respaldo original (que sigue siendo inmutable), pero permite que la versión productiva activa cumpla con la obligación de supresión sin tener que esperar a que el respaldo expire por retention.\nStaged Restore: recuperación al lab → script de sanitización → publicación del estado saneado en producción. Casos de uso de Staged Restore alineados con la Ley 21.719 # Derecho de supresión: eliminar registros de un titular en bases de datos productivas a partir de un respaldo reciente, sin tocar el respaldo inmutable. Anonimización: aplicar transformaciones (hash, máscara, generalización) antes de migrar datos a un entorno con menor nivel de control. Limpieza pre-restore tras un incidente: ejecutar verificaciones AV/EDR, aplicar parches críticos o sanitizar configuraciones inseguras antes de que la VM toque producción. Cumplimiento contractual con encargados de tratamiento: garantizar que la información compartida con un tercero no contiene datos personales más allá de lo estrictamente necesario. Secure Restore # Junto con Staged Restore, Veeam ofrece Secure Restore, que escanea automáticamente la VM con un antivirus o EDR antes de publicarla. Si bien su foco es de seguridad operacional (anti-ransomware, anti-malware), también aporta evidencia complementaria al cumplimiento, demostrando que cada restauración pasa por una validación previa formal y que no estamos reintroduciendo en producción una amenaza que pueda comprometer datos personales.\nLimitaciones que hay que tener presentes # Staged Restore opera a nivel de VM completa. Para casos más granulares, por ejemplo, eliminar un único usuario de una tabla en una base de datos sin tocar el resto del workload, se complementa con Veeam Explorer for Microsoft SQL o el Explorer correspondiente, que permite recuperación a nivel de objeto de aplicación. Para datos que viven en SaaS o servicios cloud nativos sin agente de respaldo Veeam, el flujo de borrado debe complementarse con las APIs nativas del proveedor (M365, Salesforce, etc.) y con Veeam Backup for Microsoft 365 o Veeam Backup for Salesforce, que sí soportan restauración granular y registro auditable. El script de sanitización es responsabilidad del equipo de IT; Veeam ejecuta el script pero no genera la lógica de borrado. Esto significa que la calidad del cumplimiento depende de qué tan bien escrito esté el script y de su mantenimiento en el tiempo. Recomiendo versionarlo en el mismo repositorio Git de la organización, con revisión y testing antes de cada uso productivo. Staged Restore actúa sobre el estado restaurado, no sobre los respaldos históricos. Para los respaldos del pasado, la respuesta correcta es la combinación de retention controlada al mínimo legal aplicable, inmutabilidad durante ese plazo y registro honesto, no existir un atajo técnico para \u0026ldquo;borrar selectivamente del histórico\u0026rdquo; en arquitecturas tradicionales. Lo que NO hay que hacer # No prometer al titular que su dato fue borrado del respaldo si en realidad el dato sigue ahí. La declaración correcta es que el dato ha sido suprimido del estado productivo y se mantiene en respaldos históricos durante el plazo legal mínimo, identificando cuál es ese plazo y la base legal que lo justifica. No asumir que la Ley 21.719 exige el borrado físico inmediato del histórico. La ley exige medidas razonables y proporcionales, no imposibles. Una retention controlada + inmutabilidad + Staged Restore + documentación honesta es una respuesta defendible. No buscar atajos técnicos que prometen \u0026ldquo;borrar selectivamente del respaldo\u0026rdquo;. En arquitecturas tradicionales no existen. Lo que existe es Staged Restore para el estado productivo y retention bien gestionada para que los históricos expiren en el plazo justo. No olvidar que la honestidad del registro es lo que diferencia un proceso defendible de uno que no resiste fiscalización. El regulador tolera una arquitectura imperfecta documentada con honestidad mucho mejor que una arquitectura \u0026ldquo;ideal en papel\u0026rdquo; que no se sostiene cuando se rasca un poco. Minimización y limitación del plazo de conservación # El principio de minimización exige que solo conservemos los datos personales por el tiempo necesario para cumplir la finalidad declarada del tratamiento. En el contexto de respaldos, esto se traduce en políticas de retention y GFS justificadas documentalmente.\nGFS no es decorativo. Cada plazo de retención debe estar respaldado por un fundamento legal, contractual u operacional. Algunos ejemplos típicos:\nDatos contables y facturas: 6 años por obligación tributaria del Servicio de Impuestos Internos. Logs de acceso a sistemas críticos: 1 año por compliance interno y trazabilidad ante incidentes. Datos de marketing y CRM: el plazo del consentimiento entregado por el titular, típicamente entre 1 y 3 años con opción de renovación. Datos de salud o sensibles: el plazo declarado en el Registro de Actividades de Tratamiento, típicamente alineado con la normativa sectorial aplicable. Veeam permite configurar políticas GFS por job con granularidad diaria, semanal, mensual y anual. Lo importante desde el punto de vista de cumplimiento es que el reporte de retention de Veeam ONE coincida con lo declarado en el RAT, y que cualquier desviación esté documentada y justificada.\nNotificación de brechas en 72 horas # El Art. 14 sexies establece la obligación de notificar a la Agencia y, según la gravedad, a los titulares afectados. La ventana de 72 horas se cuenta desde el conocimiento de la brecha, no desde la brecha misma. Esto significa que el reloj parte cuando alguien dentro de la organización (típicamente el equipo de IT o el SOC) detecta la situación. Si la detección demora días, el plazo de 72 horas se cuenta desde ese momento, pero la demora en detectar puede ser interpretada como una falla del control de monitoreo, configurando una infracción adicional.\nCapacidades de Veeam para detección temprana # La Plataforma de Veeam incorpora varias capacidades específicas para acortar el tiempo de detección:\nVeeam Recon Scanner: análisis automatizado de los respaldos en busca de indicadores de compromiso, incluyendo IOCs conocidos y comportamientos anómalos en los datos respaldados.\nThreat Center: dashboard centralizado que correlaciona eventos de seguridad detectados durante los respaldos, con priorización por severidad.\nMalware Detection con análisis de entropía: detección automatizada de cifrado anómalo en archivos, característico de un evento de ransomware en curso.\nAlertas de borrado masivo: notificación inmediata cuando se detecta eliminación atípica de datos en los respaldos o en las cargas protegidas.\nRunbook conectado con NIST 800-61 # Una vez detectada la brecha, el flujo de respuesta debe estar documentado y ensayado. Esto se conecta directamente con lo que ya conversamos en el post de Plan de Respuesta ante Incidentes con NIST 800-61, 800-53r5, Mitre ATT\u0026amp;CK y Veeam, y con las capacidades de detección perimetral del post de Veeam Decoys - Detección Temprana.\nEl flujo recomendado es:\nDetección Veeam (Recon Scanner, Threat Center, Decoys, Malware Detection). Análisis y triage del incidente por el CSIRT. Contención mediante aislamiento de red, revocación de credenciales y activación del Hardened Repository como sitio limpio. Erradicación y recovery desde el último punto inmutable verificado. Notificación formal a la Agencia dentro de las 72 horas, con la información requerida por la ley (naturaleza, categorías y cantidad aproximada de titulares afectados, consecuencias probables y medidas adoptadas). Notificación a los titulares afectados cuando la brecha represente un alto riesgo a sus derechos. Análisis post-mortem y actualización del plan de respuesta. Transferencia internacional: todo respaldo que cruza la frontera es transferencia # Cuando replicamos un respaldo a S3 en us-east-1 o a Azure East-US, estamos realizando una transferencia internacional de datos personales sujeta a las disposiciones de los Art. 27 y 28 de la ley (transferencia a países con nivel adecuado y cláusulas tipo, respectivamente), con la fiscalización general establecida en el Art. 29. Este es un punto que muchas organizaciones pasan por alto en la fase de diseño de su arquitectura de respaldo, y que después es muy costoso corregir.\nMecanismos de garantía aceptados por la ley # La Ley 21.719 admite varios mecanismos para que una transferencia internacional sea válida:\nPaíses con nivel adecuado de protección: la Agencia mantendrá un listado de países cuya legislación es considerada equivalente. Hasta que ese listado esté publicado, la práctica recomendada es trabajar con la presunción de que la mayoría de los destinos requerirán garantías adicionales.\nCláusulas tipo: contratos estandarizados aprobados por la Agencia que se incorporan al contrato de servicios con el proveedor cloud.\nReglas Corporativas Vinculantes (BCR): aplicables a transferencias intra-grupo en organizaciones multinacionales.\nConsentimiento expreso del titular: aplicable en algunos casos puntuales, no recomendado como base general para infraestructura de respaldo.\nDocumentación en el RAT # Toda transferencia internacional debe estar reflejada en el Registro de Actividades de Tratamiento, identificando el país de destino, el proveedor, la categoría de datos transferidos, la finalidad de la transferencia y el mecanismo de garantía utilizado. Si replicamos respaldos a AWS us-east-1, eso debe estar en el RAT.\nAlternativas para mantener los datos en LATAM # Una estrategia que muchas organizaciones están adoptando es minimizar la transferencia internacional eligiendo regiones de cloud o capacity tiers en LATAM. El panorama 2026 luce así:\nAWS: regiones operativas en São Paulo y México (Central), con Santiago de Chile anunciado para fines de 2026. Azure: regiones operativas en Brazil South (São Paulo), Brazil Southeast (Río de Janeiro), Mexico Central (Querétaro) y Chile Central (Santiago) con disponibilidad anunciada y rollout en curso. Google Cloud: regiones operativas en São Paulo y Santiago. Object storage on-premise con Veeam Hardened Repository + capacity tier S3-compatible (MinIO, Cloudian, Scality, Pure Storage, NetApp StorageGRID) hospedado en data centers locales del proveedor de turno o en infraestructura propia. Esta es la opción que más organizaciones reguladas están eligiendo cuando la sensibilidad de los datos no admite ninguna salida del país. Veeam Data Cloud Vault como object storage gestionado por Veeam con inmutabilidad WORM por defecto, encryption AES-256 en tránsito y reposo, logical air-gap desde producción y, particularmente relevante para presupuestos predecibles, pricing flat por TB que incluye API calls, restore y egress (a diferencia del modelo S3 puro donde estos cargos son variables y a menudo sorprenden en factura). Esta decisión no es solo de cumplimiento, también tiene impactos en latencia y costo de egress que deben evaluarse caso a caso. Muy importante: el solo hecho de que un proveedor tenga una región en LATAM no implica que tu suscripción enrute automáticamente los datos allí, la región de destino se configura explícitamente en el job de Veeam y debe documentarse en el RAT.\nSecuriti AI (ahora parte de Veeam): DSPM, privacy operations y AI trust # Si bien Veeam Backup \u0026amp; Replication cubre de forma sólida los pilares de integridad, disponibilidad y confidencialidad sobre los datos respaldados, hay capas del cumplimiento que ocurren aguas arriba del respaldo: descubrimiento, clasificación, gobierno de privacidad, gestión de derechos del titular, evaluaciones de impacto, que históricamente requerían herramientas externas. Eso cambió en diciembre de 2025: Veeam completó la adquisición de Securiti AI por USD 1.725 mil millones (cierre formal el 11 de diciembre de 2025), incorporando al portfolio el Data Command Center de Securiti, DSPM, privacy operations, gobierno de IA, bajo el lema \u0026ldquo;first trusted Data Platform\u0026rdquo;. Rehan Jalil, fundador y CEO de Securiti, asumió como President of Security and AI en Veeam, y los 600 colaboradores de Securiti se sumaron al equipo.\nEn la práctica, esto significa que las capacidades que detallo a continuación dejan de ser \u0026ldquo;una integración entre dos vendors\u0026rdquo; y pasan a ser piezas del mismo portfolio Veeam, con un único interlocutor comercial, un único soporte y, en el mediano plazo, integración técnica más profunda con VBR, VRO y el resto del stack. Para una organización que está armando su arquitectura de cumplimiento bajo Ley 21.719, esto baja significativamente la fricción de adopción.\nQué resuelve Securiti AI que VBR no resuelve # Data Security Posture Management (DSPM): descubrimiento automatizado de dónde viven los datos personales en toda la organización, bases de datos, data lakes, SaaS, file shares y almacenamiento cloud, con clasificación automática por categoría (datos personales identificables, datos sensibles, datos especialmente protegidos como salud o biométricos). Sin este descubrimiento previo, no sabemos qué datos estamos respaldando ni a qué jobs aplicar las políticas más estrictas.\nClasificación y etiquetado automático: identificación de RUT, datos de salud, datos financieros, datos de menores, datos biométricos, etc., usando modelos pre-entrenados. La salida de esta clasificación alimenta directamente las políticas de retention y encryption diferenciadas en Veeam.\nPrivacy Operations (DSAR): automatización del flujo de respuesta a solicitudes de los titulares (Data Subject Access Requests), acceso, rectificación, supresión, portabilidad. Esto baja el costo operacional de cumplir con los derechos del titular de días-persona a horas, y deja una trazabilidad auditable de cada solicitud y su resolución.\nConsent management: registro y trazabilidad del consentimiento entregado por cada titular, con linkage directo a las finalidades declaradas en el Registro de Actividades de Tratamiento.\nDPIA automation: workflow asistido para realizar las Evaluaciones de Impacto, con plantillas alineadas a múltiples marcos regulatorios (GDPR, LGPD, CCPA, y las que vayan emergiendo para Ley 21.719).\nCompliance automation y mapeo multi-marco: cuando una organización opera en varios países, Securiti AI permite mapear los controles implementados a múltiples leyes simultáneamente, evitando duplicar esfuerzo de documentación y manteniendo coherencia entre regulaciones que comparten principios pero difieren en detalle.\nAI security y governance: capacidades específicas para gobernar el uso de datos personales en proyectos de IA, protección de datos de entrenamiento, sanitización de prompts, trazabilidad de inferencias y de modelos derivados.\nCómo se integran en una arquitectura combinada # Una arquitectura madura de cumplimiento bajo Ley 21.719 combina ambas capas del portfolio Veeam operando en planos distintos pero coordinados:\nSecuriti AI en la capa de descubrimiento, clasificación, governance y privacy operations, actuando como el sistema de inteligencia que sabe qué datos personales existen, dónde viven, quién los procesa, con qué finalidad y bajo qué consentimiento.\nVeeam Backup \u0026amp; Replication + Recovery Orchestrator en la capa de respaldo, recuperación, inmutabilidad y respuesta a incidentes, actuando como el sistema que asegura la integridad y disponibilidad de esos datos cuando algo sale mal.\nIntegración por APIs y etiquetas: la clasificación que produce Securiti AI se traduce en políticas diferenciadas en Veeam, jobs con cifrado y KMS dedicado para datos sensibles, retention extendida para datos sujetos a obligaciones legales específicas, replicación restringida a regiones LATAM para datos que no admiten transferencia internacional, alertas de Threat Center priorizadas según la criticidad regulatoria del dataset comprometido. Esta integración irá profundizándose durante 2026 a medida que avance la unificación del portfolio post-adquisición.\nSecuriti AI descubre, clasifica y gobierna; Veeam respalda, protege y recupera; ambos generan la evidencia que se entrega a la Agencia. Qué evidencia adicional aporta Securiti AI al regulador # Frente a un proceso de fiscalización, Securiti AI contribuye con documentación que Veeam no puede generar de forma nativa:\nReporte de inventario de datos personales por categoría y por sistema, con timestamp y trazabilidad de cambios. Registro de DSAR atendidas con tiempos de respuesta y trazabilidad de la acción ejecutada sobre los sistemas productivos. Mapeo de controles a artículos específicos de la Ley 21.719 y a marcos análogos como GDPR, LGPD o CCPA. DPIA documentadas, archivadas y con flujo formal de aprobación. Registro de consentimientos con timestamps, fuentes y trazabilidad de modificaciones. La pregunta de fondo no es Veeam o Securiti AI, la pregunta es cómo se complementan para cubrir el ciclo completo del dato personal: descubrir, clasificar, gobernar (Securiti AI) → respaldar, proteger, recuperar (Veeam) → responder y evidenciar ante el regulador (ambos en conjunto).\nCapacidades adicionales de Veeam alineadas con Ley 21.719: VRO, Coveware, Threat Hunter y más # Más allá de los pilares ya cubiertos (encryption con KMS, Hardened Repository, regla 3-2-1-1-0, Staged Restore, Recon Scanner, Threat Center), la Plataforma de Veeam tiene varias capacidades específicas que vale la pena conocer porque mapean directamente con principios de la Ley 21.719 y con las exigencias documentales que va a tener el proceso de fiscalización. Varias de estas son funcionalidades recientes incorporadas en v12.3 (early 2025) y v13 que muchas organizaciones todavía no han habilitado.\nVeeam Recovery Orchestrator (VRO): el control de disponibilidad documentado automáticamente # Veeam Recovery Orchestrator es el componente que orquesta la recuperación ante desastres y, lo que es más relevante para nuestro caso, auto-genera la documentación que el auditor va a pedir. En lugar de mantener manualmente el plan de DR, los runbooks y los reportes de pruebas, VRO los produce y los actualiza automáticamente cuando el plan se ejecuta o se prueba.\nLo que aporta para Ley 21.719:\nRunbooks automatizados que detallan paso a paso cómo se recuperan las cargas críticas que contienen datos personales, sin depender de la memoria del operador de turno. Pruebas automatizadas con registro, los DR drills se ejecutan en un entorno aislado y dejan reporte fechado del resultado, lo que constituye evidencia formal del control de disponibilidad ante el regulador. Monthly Audit Report con Full Change Tracking (incorporado en v13 de la Plataforma), registra todas las actividades y cambios sobre los planes de recuperación durante el mes, generando una trazabilidad que difícilmente vamos a producir a mano. Offline malware scanning antes del recovery, los respaldos se escanean offline antes de levantarlos a producción, evitando reintroducir amenazas que puedan comprometer datos personales en el ambiente productivo. Compliance dashboards que muestran el estado del cumplimiento de DR contra los SLAs declarados internamente y los plazos comprometidos en el RAT. Para una organización que tiene que demostrar ante la Agencia que sus medidas de disponibilidad son reales y verificables, VRO es la forma de pasar de \u0026ldquo;tenemos un plan\u0026rdquo; a \u0026ldquo;aquí están los reportes mensuales que demuestran que el plan funciona y se prueba periódicamente\u0026rdquo;.\nCoveware by Veeam: el equipo de respuesta que activamos cuando la prevención falla # Veeam adquirió Coveware en abril de 2024 y la marca opera hoy como Coveware by Veeam. Es un servicio especializado en respuesta a incidentes de extorsión cibernética y ransomware, es decir, exactamente el escenario que dispara la obligación de notificación de 72 horas bajo Ley 21.719.\nLo que aporta:\nIncident Response Retainer: contrato preventivo que da acceso prioritario al equipo de respuesta cuando ocurre el incidente. En la práctica, evitar el \u0026ldquo;scramble\u0026rdquo; inicial de buscar y contratar especialistas mientras la crisis está activa, que típicamente quema los primeros días del plazo de notificación. Negociación con actores de extorsión cuando aplique, gestionada por un equipo con miles de casos cerrados. La decisión de negociar o no es legal y de negocio, pero la capacidad técnica de hacerlo o de evitarlo profesionalmente es algo que la organización promedio no tiene internamente. Forensics y damage assessment, análisis técnico del incidente, vector de entrada, datos afectados. Esta información es exactamente lo que el regulador va a requerir como parte de la notificación formal de la brecha. Recon y Unidecrypt, herramientas propias de Coveware para análisis de costo de incidente y descifrado en casos donde sea técnicamente posible. Integración con Veeam Cyber Secure program, el programa elite de servicios de Veeam Data Platform Premium que combina Ransomware SWAT team disponible 24/7 con SLA de 30 minutos, assessments de seguridad trimestrales ejecutados por expertos Veeam, onboarding avanzado de siete fases y, para los clientes inscritos, hasta dos incidentes por año atendidos por Coveware sin costo adicional. Para Ley 21.719 esto es particularmente relevante porque la notificación de 72 horas no es solo \u0026ldquo;informar a la Agencia\u0026rdquo;: es entregar un análisis técnico que tenga sentido. Un equipo interno típico no puede producir ese análisis en tres días desde cero. Con Coveware en retainer, y más aún si la organización es cliente de Cyber Secure con SLA de 30 minutos, ese análisis empieza el día cero del incidente.\nVeeam Threat Hunter, YARA e Inline Malware Scanning: detección integrada al backup engine # Desde la versión 12.3 de Veeam Backup \u0026amp; Replication (early 2025), la Plataforma incorpora capacidades de detección que antes requerían herramientas externas:\nVeeam Threat Hunter: combina escaneo con reglas YARA, detección estilo antivirus, machine learning y análisis heurístico, todo integrado al backup engine. Detecta malware polimórfico que evade firmas tradicionales. La base de datos de amenazas se actualiza varias veces al día desde Veeam. Inline Malware Scanning: el escaneo ocurre durante el job de respaldo, no como un paso posterior. Si una VM comprometida se está respaldando con archivos cifrados por ransomware o con binarios maliciosos, la alerta es inmediata y dentro de la ventana del propio job. Indicators of Compromise (IoC) Detection: identifica patrones conocidos de ataque dentro de los datos respaldados, alimentados por threat intelligence integrada. YARA rules personalizadas: el equipo de seguridad puede definir reglas propias para detectar amenazas específicas a su industria, su entorno o un caso particular bajo investigación. Para Ley 21.719, lo crítico es el tiempo de detección. Recordemos que las 72 horas se cuentan desde el conocimiento de la brecha. Cada hora que pasa sin detectar el incidente erosiona el plazo disponible para una respuesta ordenada y para construir la notificación formal a la Agencia. Estas capacidades bajan ese tiempo de detección significativamente y, lo que es igual de importante, dejan logs auditables de cada detección y cada falso positivo descartado.\nFour-Eyes Authorization: separación de responsabilidades exigible # Otra incorporación reciente es Four-Eyes Authorization, que requiere la aprobación de un segundo operador autorizado antes de ejecutar operaciones sensibles sobre la infraestructura de respaldo: eliminar jobs, modificar políticas de retention, deshabilitar encryption, modificar configuraciones de repositorios inmutables.\nEsta capacidad ataca directamente el riesgo de insider malicioso y de acción accidental con consecuencias destructivas. Para Ley 21.719, cumple con el principio de \u0026ldquo;medidas razonables\u0026rdquo; en la separación de roles, especialmente para operaciones que afectan la retención o el borrado de datos personales, operaciones que de otro modo podrían ser usadas para evadir el cumplimiento o para destruir evidencia frente al regulador. Esto se conecta con el enfoque RBAC multi-tenant que ya conversamos en el post de Kasten RBAC multi-tenant multi-cluster con Keycloak, donde la separación de responsabilidades a nivel de plataforma se aplica también al respaldo de cargas Kubernetes.\nCada aprobación queda registrada en el audit log con ambos operadores identificados, fecha, operación realizada y justificación textual cuando aplica. Es el tipo de control que un auditor pide verificar de forma directa, y que sin Four-Eyes Authorization se construye con procesos manuales que rara vez se cumplen al 100%.\nMatriz auditable y checklist de los 12 meses previos # Para cerrar, te dejo una tabla resumen con el cruce \u0026ldquo;principio de la ley → control técnico → componente Veeam → evidencia auditable\u0026rdquo;, y un checklist de hitos para que tu organización llegue preparada al 1 de diciembre de 2026.\n¿Cómo se mapean los controles técnicos a los principios de la Ley 21.719? # La siguiente matriz traduce cada principio de la ley a un control técnico específico, su componente Veeam responsable y la evidencia documental que entregamos al regulador. Es la respuesta corta y accionable a la pregunta que casi todos los lectores van a tener al llegar acá.\nPrincipio Ley 21.719 Control técnico Componente Veeam Evidencia auditable Confidencialidad Cifrado AES-256 + KMS externo Job encryption + integración Vault/KMS Config del job, audit log KMS Integridad Inmutabilidad modo Compliance Hardened Repository + Veeam Vault Reporte Veeam ONE de inmutabilidad Disponibilidad operacional 3-2-1-1-0 + verificación SureBackup + Veeam ONE Reportes mensuales SureBackup Disponibilidad orquestada Runbooks automatizados + auditoría DR Veeam Recovery Orchestrator (VRO) Monthly Audit Report + runbooks fechados Minimización Retention justificada en RAT GFS por job Reporte de retention Veeam ONE Derecho de supresión Staged Restore + retention controlada VBR Staged Restore + GFS + inmutabilidad Job log Staged Restore + registro DSAR Detección integrada YARA + ML + IoC + Inline Scan Veeam Threat Hunter (v12.3+) Logs de detección con timestamp Notificación de brechas Detección + análisis forense Recon Scanner + Threat Center + Coveware by Veeam Runbook + logs + reporte forense Separación de roles para borrado Doble autorización en operaciones críticas Four-Eyes Authorization Audit log con dos aprobadores Transferencia internacional Cláusulas tipo + RAT Capacity tier documentado RAT actualizado Checklist de los 12 meses # Hoja de ruta sugerida para llegar al 1 de diciembre de 2026 con la documentación auditable lista. T-12 meses (diciembre 2025): implementación y prueba del KMS externo, integración con Veeam Backup \u0026amp; Replication, definición de política de rotación de llaves.\nT-9 meses (marzo 2026): despliegue del Hardened Repository en modo Compliance, migración de jobs críticos al destino inmutable, validación de aislamiento de red y de identidad.\nT-6 meses (junio 2026): realización de la DPIA del flujo de respaldo, especialmente para jobs que involucran datos sensibles o transferencia internacional. Actualización del Registro de Actividades de Tratamiento.\nT-3 meses (septiembre 2026): simulacro completo de notificación de brecha, midiendo tiempo de detección, tiempo de contención, tiempo de notificación. Ajustes al runbook según hallazgos.\nT-1 mes (noviembre 2026): auditoría externa de cumplimiento, revisión de toda la documentación que se entregaría a la Agencia ante un eventual requerimiento.\n1 de diciembre de 2026: entrada en vigencia plena de la Ley 21.719.\nPreguntas frecuentes # ¿Cuándo entra en vigencia la Ley 21.719? # La Ley 21.719 fue publicada el 13 de diciembre de 2024 y entra en plena vigencia el 1 de diciembre de 2026, 24 meses después de su publicación. Desde esa fecha, la Agencia de Protección de Datos Personales puede fiscalizar el cumplimiento y aplicar sanciones.\n¿Cuáles son las sanciones máximas de la Ley 21.719? # Hasta UTM 20.000 o el 4% de los ingresos anuales en Chile en la categoría más alta (~$1.392M CLP en su tope UTM). La reincidencia puede triplicar la multa, alcanzando hasta UTM 60.000.\n¿Las PyMES deben cumplir con la Ley 21.719 desde el día uno? # Sí, pero con un margen de adaptación: durante el primer año de vigencia (1 dic 2026 al 1 dic 2027), las PyMES están sujetas únicamente a amonestación escrita, no a multa. Pasado ese plazo, las sanciones aplican plenamente.\n¿Cómo cumplir con el derecho de supresión sobre respaldos inmutables? # Para arquitecturas tradicionales, la respuesta defendible es la combinación de Staged Restore (Veeam B\u0026amp;R 9.5 U4+) sobre el estado productivo activo, retention al mínimo legal aplicable documentada en el RAT, inmutabilidad del respaldo histórico durante ese plazo, y registro honesto que registre la acción ante el titular y el regulador.\n¿Qué es Staged Restore en Veeam? # Es una funcionalidad de Veeam Backup \u0026amp; Replication (desde 9.5 Update 4) que permite recuperar una VM desde el respaldo a un entorno aislado, ejecutar un script de sanitización (PowerShell, Bash) sobre los datos restaurados, por ejemplo eliminar registros de un titular, anonimizar campos, y publicar el estado saneado en producción. El respaldo original sigue siendo inmutable.\n¿Cómo se relaciona la Ley 21.719 con el GDPR europeo? # La Ley 21.719 toma el modelo conceptual de GDPR y replica casi todos sus principios, derechos del titular, obligaciones de DPO, DPIA y notificación de brechas en 72h. Las diferencias principales son la cuantía absoluta de sanciones, el alcance territorial (acotado a Chile en lugar de extraterritorial) y la jurisprudencia, que en Chile recién comienza a construirse.\nConclusión # La Ley 21.719 nos lleva, finalmente, a un escenario donde la protección de datos personales se traduce en obligaciones técnicas concretas y fiscalizables. Para las áreas de IT, y particularmente para los equipos a cargo de la infraestructura de respaldo y recuperación, esto representa una oportunidad para profesionalizar y documentar prácticas que muchas veces ya se aplican, pero que no estaban formalizadas como evidencia de cumplimiento.\nLa buena noticia es que la mayor parte de los controles que la ley exige se pueden implementar y evidenciar con las capacidades nativas de la Plataforma de Veeam, encryption con KMS, inmutabilidad real en modo Compliance, RBAC con MFA, retention justificada, Staged Restore para el derecho de supresión, detección automatizada con Veeam Threat Hunter y Threat Center, verificación periódica con SureBackup, orquestación con Veeam Recovery Orchestrator y respuesta especializada con Coveware by Veeam. Lo que diferencia un cumplimiento sólido de uno superficial es la disciplina de documentar cada control y mantener actualizada la matriz auditable que entregamos al regulador.\nPara las PyMES chilenas hay un margen adicional durante el primer año de vigencia (1 dic 2026 al 1 dic 2027), donde las infracciones se sancionan solo con amonestación. Pero ese período no es para \u0026ldquo;empezar después\u0026rdquo;, es para terminar de aterrizar lo que ya debiera estar en marcha: al cierre del período de gracia, los antecedentes acumulados pasan a ser parte del historial frente a la Agencia.\nSi tu organización todavía no tiene un plan claro para llegar al 1 de diciembre de 2026 con la casa en orden, la recomendación es partir hoy mismo por el checklist de los 12 meses, y avanzar de forma sistemática y documentada. Como siempre digo, en seguridad y resiliencia no hay atajos: o se hace bien, o no se hace.\nSi te sirvió este post o tienes preguntas sobre cómo aplicar estos controles en tu arquitectura específica, escríbeme por LinkedIn.\nPosts relacionados # Veeam Hardened (Immutable) Repository Veeam Decoys - Detección Temprana Veeam + Kasten Veeam Capacity Tier Oracle Cloud Object Storage ","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/posts/ley-21719-veeam/","section":"Blog","summary":"Cumplimiento técnico de la Ley 21.719 con Veeam Data Platform: encryption, inmutabilidad, Staged Restore, VRO, Threat Hunter y matriz auditable. Vigencia 1 dic 2026.","title":"Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam","type":"posts"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/ley-21719/","section":"Etiquetas","summary":"","title":"Ley-21719","type":"tags"},{"content":"","date":"7 mayo 2026","externalUrl":null,"permalink":"/en/categories/personal-data-protection/","section":"Categories","summary":"","title":"Personal Data Protection","type":"categories"},{"content":"","date":"7 mayo 2026","externalUrl":null,"permalink":"/en/tags/personal-data-protection/","section":"Tags","summary":"","title":"Personal-Data-Protection","type":"tags"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/categories/protecci%C3%B3n-de-datos-personales/","section":"Categorías","summary":"","title":"Protección De Datos Personales","type":"categories"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/proteccion-datos-personales/","section":"Etiquetas","summary":"","title":"Proteccion-Datos-Personales","type":"tags"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/securiti-ai/","section":"Etiquetas","summary":"","title":"Securiti-Ai","type":"tags"},{"content":"","date":"7 mayo 2026","externalUrl":null,"permalink":"/en/categories/security/","section":"Categories","summary":"","title":"Security","type":"categories"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/categories/seguridad/","section":"Categorías","summary":"","title":"Seguridad","type":"categories"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/staged-restore/","section":"Etiquetas","summary":"","title":"Staged-Restore","type":"tags"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/categories/veeam-backup--replication/","section":"Categorías","summary":"","title":"Veeam Backup \u0026 Replication","type":"categories"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/veeam-backup-replication/","section":"Etiquetas","summary":"","title":"Veeam-Backup-Replication","type":"tags"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/veeam-recovery-orchestrator/","section":"Etiquetas","summary":"","title":"Veeam-Recovery-Orchestrator","type":"tags"},{"content":"","date":"7 de mayo de 2026","externalUrl":null,"permalink":"/es/tags/veeam-threat-hunter/","section":"Etiquetas","summary":"","title":"Veeam-Threat-Hunter","type":"tags"},{"content":"","date":"6 abril 2026","externalUrl":null,"permalink":"/en/categories/architecture/","section":"Categories","summary":"","title":"Architecture","type":"categories"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/categories/arquitectura/","section":"Categorías","summary":"","title":"Arquitectura","type":"categories"},{"content":"","date":"6 abril 2026","externalUrl":null,"permalink":"/en/categories/backup/","section":"Categories","summary":"","title":"Backup","type":"categories"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/backup/","section":"Etiquetas","summary":"","title":"Backup","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/cisa-kev/","section":"Etiquetas","summary":"","title":"Cisa-Kev","type":"tags"},{"content":"","date":"6 abril 2026","externalUrl":null,"permalink":"/en/categories/design/","section":"Categories","summary":"","title":"Design","type":"categories"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/escaneo/","section":"Etiquetas","summary":"","title":"Escaneo","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/grype/","section":"Etiquetas","summary":"","title":"Grype","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/categories/gu%C3%ADa/","section":"Categorías","summary":"","title":"Guía","type":"categories"},{"content":"","date":"6 abril 2026","externalUrl":null,"permalink":"/en/categories/guide/","section":"Categories","summary":"","title":"Guide","type":"categories"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/jadi/","section":"Etiquetas","summary":"","title":"Jadi","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/macos/","section":"Etiquetas","summary":"","title":"Macos","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/categories/microsoft/","section":"Categorías","summary":"","title":"Microsoft","type":"categories"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/open-source/","section":"Etiquetas","summary":"","title":"Open-Source","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/categories/respaldo/","section":"Categorías","summary":"","title":"Respaldo","type":"categories"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/rest-api/","section":"Etiquetas","summary":"","title":"Rest-Api","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/restore-point/","section":"Etiquetas","summary":"","title":"Restore-Point","type":"tags"},{"content":"","date":"6 abril 2026","externalUrl":null,"permalink":"/en/tags/scanner/","section":"Tags","summary":"","title":"Scanner","type":"tags"},{"content":"","date":"6 abril 2026","externalUrl":null,"permalink":"/en/tags/scanning/","section":"Tags","summary":"","title":"Scanning","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/seguridad/","section":"Etiquetas","summary":"","title":"Seguridad","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/ssh/","section":"Etiquetas","summary":"","title":"Ssh","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/trivy/","section":"Etiquetas","summary":"","title":"Trivy","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/veeam/","section":"Etiquetas","summary":"","title":"Veeam","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/categories/vmware/","section":"Categorías","summary":"","title":"VMware","type":"categories"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/vscan/","section":"Etiquetas","summary":"","title":"Vscan","type":"tags"},{"content":" En este post veremos en detalle vScan 2.0, una aplicación de escritorio open-source que desarrollé para escanear los restore points de Veeam Backup \u0026amp; Replication v13+ en busca de vulnerabilidades de seguridad. Revisaremos la arquitectura, la instalación, configuración, las funcionalidades de escaneo, gestión de vulnerabilidades, reportes, seguridad y mucho más.\n¿Por qué escanear tus Respaldos? # Antes que nada siempre debemos preguntarnos, ¿por qué necesitamos escanear los respaldos? La respuesta es simple: si un servidor fue comprometido hace semanas y lo descubrimos hoy, todos los restore points de ese período contienen las vulnerabilidades o malware. Si necesitamos restaurar y no sabemos cuál restore point es seguro, estamos restaurando a ciegas.\nCon vScan podemos escanear cualquier restore point antes de restaurarlo, saber exactamente qué vulnerabilidades contiene y tomar una decisión informada.\nAdemás, recuerda que Veeam ya tiene incluido el análisis de entropía, malware, entre otros en la solución. Por tanto, vScan llega a ser un complemento adicional para que cuando sea necesario puedas asegurarte con las últimas publicaciones de vulnerabilidades si tu máquina o respaldo que vas a recuperar, cuenta o no con vulnerabilidades y hacer la recuperación en un ambiente aislado para aplicar la mitigación de las vulnerabilidades y luego desplegar en producción.\n¿Qué es vScan? # vScan es una aplicación de escritorio para Windows y macOS que se integra con Veeam Backup \u0026amp; Replication v13+ a través de su REST API. La aplicación monta los discos virtuales de cualquier restore point en un servidor Linux remoto vía SSH y ejecuta scanners de vulnerabilidades contra el filesystem montado.\nNo es solo un scanner, vScan provee gestión completa del ciclo de vida de las vulnerabilidades: tracking, estados, detección de fix automático, integración con el catálogo KEV de CISA, reportes PDF ejecutivos y técnicos, notificaciones por email y escritorio, batch scanning, escaneos programados y mucho más.\nLa aplicación está disponible en GitHub: https://github.com/mescobarcl/vScan\nPlataformas Soportadas # macOS Windows Versión mínima 13.0 (Ventura) 10 (1803+) Probado Ventura 13, Sonoma 14, Sequoia 15, Tahoe 26 Windows 10, 11, Server 2019/2022/2025 Arquitectura Apple Silicon (arm64) x86_64 Instalador .dmg .exe Biometría Touch ID, Face ID Windows Hello Credenciales macOS Keychain Windows Credential Manager Un servidor Linux remoto con SSH es necesario para montar los discos y ejecutar los scanners de vulnerabilidades.\nRequisitos # Para utilizar vScan necesitaremos:\nComponente Requisito Sistema Operativo Windows 10+ o macOS 13+ Veeam VBR Veeam Backup \u0026amp; Replication v13 o superior Servidor Linux Rocky Linux 9+ Scanners Trivy, Grype y Jadi Instalación # La instalación es muy simple, descargamos el instalador desde la página de releases en GitHub:\nhttps://github.com/mescobarcl/vScan/releases\nPara macOS descargamos el archivo .dmg y arrastramos la aplicación a la carpeta Applications. Para Windows descargamos el .exe y ejecutamos el instalador.\nConfiguración Inicial – Master Password # Al iniciar vScan por primera vez nos pedirá crear una Master Password. Esta contraseña protege todas las credenciales almacenadas en la aplicación usando cifrado AES-256-GCM con derivación de clave Argon2id.\nEs muy importante guardar la Recovery Key que se genera automáticamente. Esta clave en formato VSCAN-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX es la única forma de recuperar el acceso si se olvida la Master Password.\nUna vez configurada la Master Password, vScan soporta desbloqueo biométrico con Touch ID en macOS y Windows Hello en Windows para acceso rápido.\nConexión al Servidor VBR # El primer paso después de crear la Master Password es conectarnos a nuestro servidor de Veeam Backup \u0026amp; Replication. Vamos a la sección de configuración y veremos un wizard de 5 pasos que nos guiará:\nEn el Step 1 configuramos la conexión VBR:\nIngresamos el hostname o IP del servidor VBR Puerto (por defecto 9419 para REST API) Username en formato dominio\\usuario Password vScan se conecta al REST API de Veeam y obtiene automáticamente la información del servidor: versión de VBR, edición de licencia, versión de base de datos SQL, etc.\nConexión al Servidor Linux # En el Step 2 configuramos el servidor Linux que actuará como scanner host. Aquí tenemos dos opciones:\nImportar desde VBR: Si tenemos servidores Linux registrados como managed servers en VBR, podemos importarlos directamente Configuración manual: Ingresamos la IP, puerto SSH, usuario y contraseña o clave privada Al conectarnos, vScan ejecuta un proceso de setup automático de 8 pasos:\nValidar credenciales Establecer conexión SSH Aceptar Fingerprint Detectar sistema operativo Rocky Verificar e instalar paquetes del sistema Configurar Trivy scanner Configurar Grype scanner Configurar Jadi scanner Guardar configuración vScan detecta automáticamente si los scanners están instalados, cuál es su versión actual, y ofrece instalarlos o actualizarlos. Las descargas se verifican con SHA-256 antes de la instalación para prevenir tampering.\nTambién realiza verificación de host key SSH usando TOFU: la primera vez que nos conectamos a un servidor, se almacena el fingerprint. Si el fingerprint cambia en conexiones futuras, vScan nos alerta de un posible ataque Man-in-the-Middle.\nNotificaciones – Email y Desktop # vScan soporta dos canales de notificación:\nNotificaciones nativas del sistema operativo para eventos en tiempo real.\nConfiguración SMTP con STARTTLS/SSL para envío de alertas por correo.\nLos 6 tipos de eventos configurables son:\nEvento Descripción Scan Completed Cuando un escaneo finaliza exitosamente Scan Failed Cuando un escaneo falla Batch Completed Cuando un batch scan finaliza Schedule Started Cuando un escaneo programado comienza KEV Found Cuando se detecta una vulnerabilidad activamente explotada Critical Vulnerabilities Cuando se encuentran vulnerabilidades de severidad crítica Dashboard # Una vez configuradas las conexiones, la vista principal de vScan es el Dashboard que nos muestra un resumen completo de la postura de seguridad:\nEl dashboard incluye:\nContadores de vulnerabilidades por severidad: Critical, High, Medium, Low Contador KEV: vulnerabilidades que están en el catálogo de CISA Known Exploited Vulnerabilities Gráfico de distribución de severidad Tendencia de vulnerabilidades a lo largo del tiempo Top VMs más vulnerables con ranking por severidad Escaneos recientes con estado en tiempo real Estadísticas de escaneos: total, últimos 7 días, últimos 30 días Los datos se actualizan en tiempo real conforme se completan nuevos escaneos.\nTres Motores de Escaneo: Trivy, Grype y Jadi # vScan soporta tres motores de escaneo de vulnerabilidades:\nTrivy # Scanner de Aqua Security, uno de los más utilizados en la industria. Excelente para paquetes de distribuciones Linux y contenedores. vScan lo instala y gestiona automáticamente. Documentación oficial: https://github.com/aquasecurity/trivy\nGrype # Scanner de Anchore, otra opción popular para escaneo de vulnerabilidades. Complementa bien a Trivy con un enfoque diferente. Documentación oficial: https://github.com/anchore/grype\nJadi # Mi propio scanner CLI escrito en Rust, diseñado específicamente para cubrir el gap que dejan Trivy y Grype en la detección de vulnerabilidades en software binario de Windows y parches de KB. Jadi utiliza múltiples fuentes de vulnerabilidades:\nNVD (National Vulnerability Database) para matching por CPE MSRC (Microsoft Security Response Center) para vulnerabilidades de Windows y KBs OSV (Open Source Vulnerabilities) para ecosistemas de lenguajes GHSA (GitHub Security Advisories) CISA KEV (Known Exploited Vulnerabilities) Cada scanner se puede instalar, actualizar y desinstalar directamente desde la UI de vScan. Las instalaciones se verifican con SHA-256 para garantizar la integridad del binario.\nhttps://github.com/mescobarcl/jadi\nComo Escanear Respaldos # Para escanear una VM, vScan provee un wizard guiado de 5 pasos:\nPaso 1: Seleccionar VMs # Seleccionamos la VM que queremos escanear. vScan obtiene la lista de VMs directamente desde la API de VBR\nPaso 2: Seleccionar Restore Point # Elegimos el restore point que queremos escanear. Se muestra la fecha, tipo y tamaño de cada punto de restauración disponible.\nPaso 3: Seleccionar Discos # Seleccionamos cuáles discos de la VM queremos montar y escanear. Podemos seleccionar todos o solo algunos específicos.\nPaso 4: Montar Discos # vScan publica el restore point a través del Data Integration API de Veeam y monta los discos en el servidor Linux usando FUSE o iSCSI. Se muestra el progreso del montaje en tiempo real.\nPaso 5: Escaneo y Resultados # Una vez montados los discos, se ejecuta el scanner seleccionado contra el filesystem. El progreso se muestra en tiempo real con ETA estimado.\nAl finalizar vemos los resultados con el total de vulnerabilidades encontradas por severidad:\nGestión del Ciclo de Vida de Vulnerabilidades # Esta es una de las funcionalidades más importantes de vScan 2.0. No es solo un scanner, es una plataforma de gestión del ciclo de vida de vulnerabilidades.\nBrowser de Vulnerabilidades # El browser permite filtrar y buscar vulnerabilidades con múltiples criterios:\nSeveridad: Critical, High, Medium, Low, Negligible Estado: Open, Fixed, Won\u0026rsquo;t Fix, Accepted, False Positive VM Name: filtrar por servidor específico Package Name: buscar por paquete afectado Scanner Type: filtrar por Trivy, Grype o Jadi Rango de fechas: primera detección o última detección KEV: solo vulnerabilidades en el catálogo CISA Lifecycle Tracking # Cada vulnerabilidad se trackea con timestamps completos:\nPrimera detección: cuándo se encontró por primera vez Última vez vista: cuándo fue la última vez que apareció en un escaneo Auto-fix: si una vulnerabilidad no aparece en un escaneo posterior, se marca automáticamente como \u0026ldquo;fixed\u0026rdquo; Reapertura: si una vulnerabilidad marcada como fixed reaparece, se reabre automáticamente Historial por escaneo: en cuáles escaneos exactamente fue detectada (audit trail completo) Gestión de Estados # Los estados disponibles son:\nEstadoDescripciónOpenVulnerabilidad detectada y pendiente de remediaciónFixedRemediada (se marca automáticamente cuando no aparece en un nuevo escaneo)Won\u0026rsquo;t FixSe decide no remediar (con justificación)AcceptedRiesgo aceptado por la organizaciónFalse PositiveDetección incorrecta del scanner\nLas operaciones de estado también se pueden hacer en bulk para gestionar múltiples vulnerabilidades simultáneamente.\nCISA KEV – Known Exploited Vulnerabilities # vScan se integra con el catálogo de Known Exploited Vulnerabilities (KEV) de CISA, que se sincroniza automáticamente cada 24 horas.\nCada vulnerabilidad detectada se cruza contra este catálogo. Las que aparecen ahí se marcan con un flag especial porque significa que esa vulnerabilidad está siendo explotada activamente. La prioridad de remediación debería ser inmediata.\nLa validación del catálogo incluye verificación de integridad: conteo de entradas, formato de CVE IDs y estructura JSON para mitigar inyección de datos maliciosos.\nDocumentación # vScan incluye documentación completa en dos idiomas:\nIdioma Link English docs/en/ Español docs/es/ Conclusión # vScan 2.0 transforma tu infraestructura de respaldos de Veeam en una plataforma de monitoreo continuo de seguridad. En lugar de esperar que ocurra un incidente para descubrir vulnerabilidades en tus restore points, ahora puedes escanearlos proactivamente, trackear el ciclo de vida de cada vulnerabilidad y tomar decisiones informadas antes de restaurar.\nLas principales funcionalidades que cubrimos en este post son:\nIntegración nativa con Veeam VBR v13+ REST API Tres motores de escaneo: Trivy, Grype y Jadi Comparación entre scanners y restore points Batch scanning con paralelismo configurable Escaneos programados con expresiones cron Gestión completa del ciclo de vida de vulnerabilidades Integración con CISA KEV (Known Exploited Vulnerabilities) Reportes ejecutivos y técnicos en PDF con branding Export CSV hasta 50,000 vulnerabilidades Notificaciones por email y desktop (6 tipos de eventos) Seguridad con AES-256-GCM, Argon2id, Keychain, biometría Auto-lock, brute force protection, recovery key System tray con menú completo Dark mode Mantenimiento automático de base de datos Documentación en inglés y español La aplicación está disponible en GitHub bajo licencia MIT: https://github.com/mescobarcl/vScan\nY con eso finalizamos este post! Cualquier idea o sugerencia es bienvenida como siempre!\nPosts relacionados # JADI Scanner Veeam Decoys - Detección Temprana Plan de Respuesta ante Incidentes con NIST 800-61, 800-53r5, Mitre ATT\u0026amp;CK y Veeam Veeam Hardened (Immutable) Repository ","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/posts/vscan-vulnerability-scanner-2-0/","section":"Blog","summary":"vScan 2.0, app open-source para escanear restore points de Veeam Backup \u0026 Replication con Trivy, Grype y Jadi. Lifecycle, CISA KEV, reportes PDF.","title":"vScan Vulnerability Scanner 2.0","type":"posts"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/vulnerabilidades/","section":"Etiquetas","summary":"","title":"Vulnerabilidades","type":"tags"},{"content":"","date":"6 abril 2026","externalUrl":null,"permalink":"/en/tags/vulnerabilitites/","section":"Tags","summary":"","title":"Vulnerabilitites","type":"tags"},{"content":"","date":"6 de abril de 2026","externalUrl":null,"permalink":"/es/tags/windows/","section":"Etiquetas","summary":"","title":"Windows","type":"tags"},{"content":"","date":"25 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/24xsiempre/","section":"Etiquetas","summary":"","title":"24Xsiempre","type":"tags"},{"content":"","date":"25 marzo 2026","externalUrl":null,"permalink":"/en/tags/backup-scan/","section":"Tags","summary":"","title":"Backup-Scan","type":"tags"},{"content":"","date":"25 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/backups/","section":"Etiquetas","summary":"","title":"Backups","type":"tags"},{"content":"","date":"25 de marzo de 2026","externalUrl":null,"permalink":"/es/categories/cloud/","section":"Categorías","summary":"","title":"Cloud","type":"categories"},{"content":"","date":"25 de marzo de 2026","externalUrl":null,"permalink":"/es/categories/dise%C3%B1o/","section":"Categorías","summary":"","title":"Diseño","type":"categories"},{"content":"","date":"25 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/forensics/","section":"Etiquetas","summary":"","title":"Forensics","type":"tags"},{"content":" En algo que vengo trabajando desde hace varios meses y que finalmente está tomando forma es Jadi, un escáner de vulnerabilidades diseñado específicamente para analizar backups montados y sistemas de archivos. El nombre no es casualidad, JADI son las iniciales de mis hijos, así que este proyecto tiene un significado especial para mí más allá de lo técnico. En este post les voy a contar de qué se trata, por qué lo construí, cómo funciona por dentro y cuáles son los planes a futuro.\n¿Por qué Jadi? # Quienes me conocen saben que llevo varios años trabajando con tecnologías de Cloud, Kubernetes, IA, protección de datos, respaldos y seguridad. Y en ese camino, una pregunta que siempre aparece en escenarios de respuesta ante incidentes y análisis forense es: ¿qué software vulnerable tenía ese sistema cuando fue comprometido / Vulnerado?\nExisten herramientas excelentes para escaneo de vulnerabilidades como Trivy y Grype y las recomiendo totalmente para ambientes Linux, containers e imágenes. Hacen un trabajo hermoso, pero cuando el escenario involucra sistemas operativos Windows, registry hives, KBs instalados, cadenas de supersedencia de parches de Microsoft, la historia cambia bastante. La cobertura de Windows en estas herramientas es limitada o inexistente y eso es un problema real cuando la mayoría de los entornos empresariales siguen corriendo Windows en sus servidores y estaciones de trabajo.\nAdemás, las herramientas existentes están pensadas para escanear sistemas en ejecución, agentes instalados, containers corriendo, repositorios activos. Pero cuando tienes un backup montado en modo solo lectura, un snapshot de un servidor que ya no existe, o una imagen forense de un disco, la mayoría de las soluciones simplemente no aplican.\nEsa combinación de necesidades, escaneo offline de backups + cobertura real de Windows. es lo que me motivó a empezar a trabajar en esta idea hace meses. Ahí es donde entra Jadi. La idea es simple pero poderosa: montar un backup, escanearlo, y obtener un reporte completo de vulnerabilidades conocidas sin necesidad de instalar nada en el sistema original.\n¿Qué hace Jadi? # El proyecto se encuentra en github.com/mescobarcl/jadi y actualmente está en la versión 0.1.0 con release publicado para Linux x86_64. Es un binario escrito en Rust que corre en tu máquina local o servidor linux y analiza cualquier filesystem montado, de preferencia Microsoft Windows.\n12 Scanners de Ecosistemas # Jadi detecta software analizando archivos de configuración y manifiestos de múltiples ecosistemas: npm, PyPI, Maven, Gradle, Go, NuGet, Composer (PHP), RubyGems, Cargo (Rust), .NET y archivos JAR. Además hace binary pattern matching para detectar versiones de OpenSSL, Apache, nginx, PHP, MySQL, PostgreSQL, Redis y Node.js directamente desde binarios.\nAnálisis de Windows Offline # Parsea registry hives (SOFTWARE, NTUSER.DAT) sin necesidad de que Windows esté corriendo. Detecta software instalado, KBs/hotfixes, versiones de Windows y .NET Framework. Además resuelve cadenas de supersedencia de parches de Microsoft, algo que muy pocas herramientas hacen correctamente.\n5 Fuentes de Vulnerabilidades # Correlaciona el software detectado contra NVD, OSV, MSRC, GitHub Security Advisories (GHSA) y CISA KEV. La base de datos de vulnerabilidades se actualiza diariamente de forma automática en el CDN, y al ejecutar jadi update-db se descarga la versión más reciente verificando integridad con SHA256.\nImportante: Dado que la base de datos se actualiza todos los días con nuevas vulnerabilidades, es recomendable siempre ejecutar jadi update-db antes de cada escaneo para asegurarte de estar trabajando con la información más reciente. Nuevos CVEs se publican constantemente y un día de diferencia puede significar no detectar una vulnerabilidad crítica.\nInteligencia KEV y Ransomware # No solo te dice qué vulnerabilidades tienes, sino cuáles están siendo activamente explotadas según el catálogo de CISA, y cuáles están asociadas a campañas de ransomware conocidas. Esto es clave para priorización en escenarios de respuesta ante incidentes.\nSBOM Generation # Genera inventarios de software en formatos SPDX 2.3 y CycloneDX 1.5, que es exactamente lo que se necesita para compliance.\n7 Formatos de Salida # Table (con colores para la terminal), JSON, SARIF (para CI/CD), CSV, Markdown, SPDX y CycloneDX. Además incluye exit codes basados en severidad (0 = limpio, 2 = críticas encontradas), lo que lo hace perfecto para integración en pipelines.\nEjemplo Rápido # # Instalar (Linux x86_64) curl -LO https://github.com/mescobarcl/jadi/releases/latest/download/jadi-linux-x86_64 chmod +x jadi-linux-x86_64 \u0026amp;\u0026amp; sudo mv jadi-linux-x86_64 /usr/local/bin/jadi # Descargar la base de datos de vulnerabilidades jadi update-db # Escanear un backup montado jadi scan /mnt/backup # Solo vulnerabilidades críticas en KEV asociadas a ransomware jadi scan /mnt/backup --min-severity critical --kev-only --ransomware-only # Generar SBOM en formato SPDX jadi scan /mnt/backup -o spdx -f sbom.spdx.json La salida en terminal se ve algo así:\nArquitectura # La arquitectura de Jadi está diseñada en capas bien definidas:\nCapa de Scanners: 12 scanners especializados que recorren el filesystem buscando archivos de configuración, manifiestos, lockfiles, registry hives y binarios. Cada scanner genera una lista de software detectado en formato PURL o CPE.\nCapa de Matchers: 4 matchers que correlacionan el software detectado con las bases de datos de vulnerabilidades. El PURL Matcher consulta OSV y GHSA, el CPE Matcher consulta NVD, el KB Matcher consulta MSRC (con resolución de supersedencia de KBs), y el KEV Matcher enriquece los resultados con datos de explotación activa de CISA.\nBase de Datos: Una base de datos local unificada de ~500MB que contiene todas las vulnerabilidades de las 5 fuentes. Se actualiza diariamente desde el CDN con un simple jadi update-db. La verificación de integridad es automática, checksum SHA256, actualizaciones incrementales, conexiones HTTPS y protección contra respuestas maliciosas.\nCapa de Output: Genera reportes en cualquiera de los 7 formatos soportados, con filtros por severidad, KEV, ransomware y reglas de eliminación u omisión configurables con fecha de expiración.\nDecisiones Técnicas # Algunas decisiones de diseño que vale la pena mencionar:\n¿Por qué Rust? Performance y seguridad de memoria. Cuando estás escaneando un filesystem con miles de archivos, parseando lockfiles JSON/YAML/TOML, y haciendo matching paralelo contra cientos de miles de CVEs, necesitas que la herramienta sea rápida. Rust nos da eso sin sacrificar seguridad. Actualmente el codebase tiene alrededor de 80 archivos .rs y más de 525 tests.\n¿Por qué SQLite local en lugar de APIs directas? Originalmente el scanner consultaba las APIs de vulnerabilidades directamente, pero esto tenía problemas serios: dependencia de red, rate limits, latencia, y la imposibilidad de usar la herramienta en ambientes air-gapped. Migrar a una base de datos pre-construida y distribuida vía CDN resolvió todo esto de golpe. Ahora puedes descargar la DB una vez, desconectarte de internet, y escanear todo lo que necesites con --offline.\n¿Por qué Cloudflare R2 como CDN? Egress gratuito. Cuando distribuyes un archivo de ~500MB a potencialmente muchos usuarios, el costo de egress en S3 o GCS escala rápido. Con R2 el costo de infraestructura es prácticamente cero.\nConfiguración flexible: Jadi soporta configuración vía TOML para reglas de eliminación u omisión de vulnerabilidades, útil cuando ya conoces ciertos hallazgos y quieres excluirlos del reporte. Las supresiones incluyen fecha de expiración para que no se olviden en el tiempo.\nCasos de Uso # ¿Dónde encaja Jadi en tu flujo de trabajo?\nAnálisis Forense / Respuesta ante Incidentes: Tienes un backup de un servidor comprometido. Lo montas en modo solo lectura y ejecutas Jadi para identificar qué vulnerabilidades existían al momento del backup. ¿Había Log4Shell? ¿Había un Exchange sin parchar? Respuesta inmediata.\nAuditoría de Compliance: Necesitas generar un SBOM de un sistema legacy para cumplir con regulaciones. Montas el backup, generas el inventario en SPDX o CycloneDX, y tienes tu evidencia de compliance.\nEvaluación de Riesgo Pre-Restauración: Antes de restaurar un backup en producción, escanéalo. Si tiene vulnerabilidades críticas con exploits activos (KEV), mejor saberlo antes de ponerlo en producción nuevamente o conectado a internet.\nVerificación de Backups: Como parte de tu proceso de verificación de backups (que todos deberían tener), agrega un escaneo de vulnerabilidades. No solo verificas que el backup sea válido, sino que el sistema respaldado no era un riesgo.\nOpciones de Performance # Para backups grandes, Jadi ofrece varias opciones de optimización:\n# Aumentar threads de escaneo jadi scan /mnt/backup --threads 16 # Matching paralelo con pool de conexiones jadi scan /mnt/backup --pool-size 8 --parallel-match # Skip carpetas ruidosas de Windows (WinSxS) jadi scan /mnt/windows-backup --skip-windows-noise # Excluir carpetas específicas jadi scan /mnt/backup \\ --exclude-path \u0026#34;node_modules\u0026#34; \\ --exclude-path \u0026#34;.git\u0026#34; \\ --exclude-path \u0026#34;vendor\u0026#34; # Limitar profundidad de búsqueda jadi scan /mnt/backup --max-depth 10 Qué Viene # El proyecto está en v0.1.0 y hay mucho camino por delante. Algunas de las áreas en las que estoy trabajando:\nMejorar las pruebas del código con inyección de dependencias y traits de repositorio Optimización de performance con regex caching y reducción de cloning innecesario Expandir la cobertura de testing, especialmente en los módulos de sincronización Refactoring de algunos módulos Documentación más completa Integración con vScan # Pero lo que más me entusiasma de lo que viene es la integración con vScan. Para quienes no lo conocen, vScan es una herramienta que permite escanear vulnerabilidades directamente desde los backups de Veeam. Hoy en día vScan ya tiene soporte para Trivy y Grype como motores de escaneo, que como mencioné antes son excelentes para ambientes Linux y containers. Próximamente en vScan 2.0.0 se agregará soporte para Jadi, lo que va a permitir cubrir el gap que hoy existe con Windows escanear backups de servidores y estaciones de trabajo Windows con la misma facilidad con la que hoy se escanean containers y Linux.\nLa integración ya está preparada del lado de Jadi, la salida JSON genera un formato compatible que vScan detecta automáticamente, permitiendo que los resultados se integren de forma nativa en el flujo de trabajo de protección de datos con Veeam. Esto significa que vas a poder escanear tus backups de Veeam en busca de vulnerabilidades como parte de tu proceso de verificación y restauración, ahora también en Windows.\nCuando lance vScan 2.0.0 actualizaré este post con todos los detalles de la integración, incluyendo ejemplos de uso, arquitectura de la solución completa, y casos de uso específicos para ambientes Veeam. Así que estén atentos. O generare otro post con todos los detalles de vScan.\nConclusión # Jadi nació de una necesidad real que vi en nuestra industria: la falta de herramientas especializadas para evaluar la postura de seguridad de backups y sistemas offline. Es gratuito, está escrito en Rust para máxima performance, soporta una cantidad considerable de ecosistemas y fuentes de vulnerabilidades y está diseñado para integrarse en flujos de trabajo existentes.\nSi trabajas con backups, análisis forense, respuesta ante incidentes, o simplemente quieres saber qué vulnerabilidades tiene ese servidor que respaldaste la semana pasada, dale una oportunidad a Jadi.\nEl repositorio está disponible en github.com/mescobarcl/jadi. Como siempre, cualquier feedback, reporte de bugs o feature request es bienvenido a través de los issues.\n¡Y como sabes, estoy disponible 24xSiempre!\nPosts relacionados # vScan Vulnerability Scanner 2.0 Veeam Decoys - Detección Temprana Plan de Respuesta ante Incidentes con NIST 800-61, 800-53r5, Mitre ATT\u0026amp;CK y Veeam Veeam Hardened (Immutable) Repository ","date":"25 de marzo de 2026","externalUrl":null,"permalink":"/es/posts/jadi-scanner/","section":"Blog","summary":"En algo que vengo trabajando desde hace varios meses y que finalmente está tomando forma es Jadi, un escáner de vulnerabilidades diseñado específicamente para analizar backups montados y sistemas de archivos. El nombre no es casualidad, JADI son las iniciales de mis hijos, así que este proyecto tiene un significado especial para mí más allá de lo técnico. En este post les voy a contar de qué se trata, por qué lo construí, cómo funciona por dentro y cuáles son los planes a futuro.","title":"JADI Scanner","type":"posts"},{"content":"","date":"25 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/rust/","section":"Etiquetas","summary":"","title":"Rust","type":"tags"},{"content":"","date":"25 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/sbom/","section":"Etiquetas","summary":"","title":"Sbom","type":"tags"},{"content":"","date":"25 marzo 2026","externalUrl":null,"permalink":"/en/tags/vulnerability/","section":"Tags","summary":"","title":"Vulnerability","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/automate/","section":"Etiquetas","summary":"","title":"Automate","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/control-file/","section":"Etiquetas","summary":"","title":"Control-File","type":"tags"},{"content":"","date":"11 julio 2025","externalUrl":null,"permalink":"/en/tags/database-recovery/","section":"Tags","summary":"","title":"Database-Recovery","type":"tags"},{"content":"","date":"11 julio 2025","externalUrl":null,"permalink":"/en/tags/dbid-recovery/","section":"Tags","summary":"","title":"Dbid-Recovery","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/estrategia-respaldo-oracle/","section":"Etiquetas","summary":"","title":"Estrategia-Respaldo-Oracle","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/categories/oracle/","section":"Categorías","summary":"","title":"Oracle","type":"categories"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/oracle/","section":"Etiquetas","summary":"","title":"Oracle","type":"tags"},{"content":"","date":"11 julio 2025","externalUrl":null,"permalink":"/en/tags/oracle-backup/","section":"Tags","summary":"","title":"Oracle-Backup","type":"tags"},{"content":"","date":"11 julio 2025","externalUrl":null,"permalink":"/en/tags/oracle-backup-strategy/","section":"Tags","summary":"","title":"Oracle-Backup-Strategy","type":"tags"},{"content":"","date":"11 julio 2025","externalUrl":null,"permalink":"/en/tags/oracle-recovery/","section":"Tags","summary":"","title":"Oracle-Recovery","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/oracle-rman/","section":"Etiquetas","summary":"","title":"Oracle-Rman","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/plugin-oracle-veeam/","section":"Etiquetas","summary":"","title":"Plugin-Oracle-Veeam","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/recuperaci%C3%B3n-dbid/","section":"Etiquetas","summary":"","title":"Recuperación-Dbid","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/restore-rman/","section":"Etiquetas","summary":"","title":"Restore-Rman","type":"tags"},{"content":"","date":"11 julio 2025","externalUrl":null,"permalink":"/en/tags/rman-backup/","section":"Tags","summary":"","title":"Rman-Backup","type":"tags"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/spfile/","section":"Etiquetas","summary":"","title":"Spfile","type":"tags"},{"content":" Una de las preguntas frecuentes que siempre estoy recibiendo es cómo realizar la recuperación de bases de datos con Veeam Explorer for Oracle, lo cual tiene distintas formas de realizar cuando se usa Veeam Oracle Plugin, que comúnmente se usa en instalaciones de RAC como también en instalaciones donde la base de datos Oracle es standalone. En particular este post es solo para realizar la instalación de Veeam Plugin desde la consola de Veeam Backup \u0026amp; Replication como también, revisaremos las opciones de recuperación cuando se realizan respaldos a través del Plugin de RMAN.\nIntroducción # Siempre existe la pregunta de cómo hacer los respaldos y recuperación de Oracle fácilmente con Veeam, o cómo funcionan los respaldos de RMAN con Veeam, solo leyendo la documentación del helpcenter de Veeam se entiende todo, pero, tradicionalmente, ¿quién lee los manuales de forma completa? :)\nOracle Recovery Manager / RMAN # Siempre debemos tomar en cuenta la documentación tanto de Oracle RMAN y Veeam para hacer este tipo de respaldos y recuperación, sobre todo para entender claramente el funcionamiento si no se tiene conocimientos de las soluciones en profundidad:\nRMAN: https://docs.oracle.com/en/database/oracle/oracle-database/23/bradv/introduction-backup-recovery.html Veeam Plugins for Oracle RMAN: https://helpcenter.veeam.com/docs/backup/plugins/rman_plugin.html?ver=120 Veeam Explorer for Oracle: https://helpcenter.veeam.com/docs/backup/explorers/rman_backups.html?ver=120 Recordemos que ya hace unas versiones atrás Veeam, soporta la gestión centralizada de la instalación de los plugins para bases de datos, Managed Mode, y la versión tradicional Unmanaged Mode, la gran diferencia es que desde el primer modo será administrado completamente por el Veeam Backup Server y el segundo modo es que el plugin enviará los respaldos a los repositorios de Veeam Backup que se configuren, pero, no tendrá ninguna gestión desde Veeam Backup Server, excepto para las recuperaciones.\nInstalación de Plugins Oracle desde Veeam Backup # La instalación en servidores Oracle Standalone o RAC, es sencilla ya que solo se debe crear un \u0026ldquo;Protection Group\u0026rdquo; dentro de Veeam Backup, agregar los servidores que deseamos instalar el plugin para luego configurar qué tipo de plugin y si se debe mantener actualizado, al igual como se hace actualmente con los agentes de Veeam para Windows, Linux, etc.\nEn caso de no usar root, puedes usar una cuenta con permisos sudo, ya que son necesarios los privilegios administrativos para instalar nuestro plugin.\nEn esta etapa es importante, ya que como aparece en la imagen anterior, debemos decidir si instalar el agente de respaldo, instalar el plugin o ambos, para este caso solo seleccionaremos \u0026ldquo;Install application plug-ins to be installed\u0026rdquo; y luego haremos clic en \u0026ldquo;Configure…\u0026rdquo; para seleccionar el plugin a instalar\nLuego clic en siguiente o next para ver que todo está configurado de la forma correcta:\nY por último clic en Finish para ver el estado de la instalación de ambos nodos\nLa instalación ya está completa, en la imagen anterior se ve el resultado y en la lista de los servidores aparece que el plugin está instalado en cada máquina.\nConfiguración Política de Respaldo para Oracle RMAN # Ahora es tan simple como generar la nueva política de respaldo para proteger las bases de datos existentes, en este caso respaldaremos la base de datos \u0026ldquo;AUSTIN\u0026rdquo; para después probar las opciones de recuperación:\nDespués seleccionar el Storage o repositorio donde dejaremos nuestros respaldos, debemos indicar la credencial a utilizar para hacer un respaldo correcto y consistente, seleccionar las credenciales de sistema operativo o de base de datos, en este caso usaremos el usuario \u0026ldquo;oracle\u0026rdquo;\nEn la máquina anterior define qué hacer con los archive logs, cuántos canales se usarán para los archive logs y en caso de existir Pluggable Databases la selección de esas bases o exclusión. Por último el Schedule y Finalizar el Wizard. Luego Veeam Backup mostrará cuándo se va a ejecutar:\nEn este caso forzaremos un respaldo de la base de datos para hacer las pruebas y veremos la ejecución exitosa del respaldo:\nRecuperación a otra Instancia Oracle - Instancia Original # Para recuperar existen múltiples formas, pero para este ejemplo, usaremos 4 formas de recuperación:\nRecuperar la base de datos a la misma instancia original Recuperar la base de datos a la misma instancia original pero con otro nombre de base de datos Recuperar la base de datos a otra instancia con el nombre y DBID original Recuperar la base de datos a otra instancia pero con otro nombre de base de datos Comenzando con la primera, solo debemos ingresar a Veeam Backup \u0026amp; Replication, ir a \u0026ldquo;Backup -\u0026gt;Disk\u0026rdquo;, seleccionar el respaldo de Oracle RMAN y hacer clic en \u0026ldquo;Restore from Oracle RMAN…\u0026rdquo;\nAbrirá el Veeam Explorer for Oracle y nos mostrará las bases de datos protegidas, en este caso, AUSTIN, seleccionamos la base de datos y hacemos clic en \u0026ldquo;Restore\u0026rdquo;:\nSeleccionamos la instancia donde recuperar, en este caso, la original de donde obtuvimos el respaldo e ingresamos con el usuario \u0026ldquo;oracle\u0026rdquo;:\nComo vamos a recuperar a la misma instancia, el requerimiento siempre es tener \u0026quot; At least an empty database with the same name and DBID must exist on the specified server\u0026quot; el texto anterior es muy importante cuando se requiere preservar el mismo nombre de la base de datos luego next y seleccionaremos el restore point que se necesite, en este caso usar el último restore point disponible.\nDespués Seleccionamos dónde quedan los archivos:\nY por último cuántos canales de RMAN usaremos para recuperar. Recuerda que hay un post en este blog donde se explica en detalle cómo funcionan los canales de RMAN.\nY después solo queda esperar la recuperación:\nRecuperar la DB a la misma instancia original | Diferente Nombre DB # Hacemos los mismos pasos anteriores, pero lo que cambia aquí es el nombre de la instancia que vamos a recuperar, en este caso usaremos \u0026ldquo;TEXAS\u0026rdquo;, por tanto cuando se llegue a la siguiente pantalla es posible cambiar el nombre:\nDespués seleccionar qué restore point usar para recuperar, indicarle que genere un nuevo DBID:\nY por último indicar o revisar los path de dónde se generan las carpetas para la recuperación con el nuevo nombre:\nLuego restaurar y ver el estado de la restauración:\nRecuperar la DB a otra instancia con el nombre y DBID original # Aquí en esta opción hay que revisar la documentación de Oracle RMAN para entender correctamente la forma de recuperar la base de datos, con el mismo nombre y el mismo DBID del respaldo, de hecho en el siguiente link se indica el procedimiento con RMAN para recuperar a otro servidor o host:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/21/bradv/rman-recovery-advanced.html#GUID-0EE8068A-5D2F-41FF-BDB9-DEEC8CBCCDB9 En resumen, lo que indica la documentación de Oracle RMAN, es que siempre es necesario para restaurar la base de datos con el mismo nombre, se debe conservar el DBID de la base de datos, usar el control file respaldado con la configuración de AUTOBACKUP que hace Veeam y por supuesto el SPFILE, por tanto, para hacer más fácil y accesible la preparación del servidor de destino, tengo el siguiente script para ejecutar en el servidor donde se desea recuperar con el Veeam Explorer para Oracle RMAN\nhttps://github.com/mescobarcl/veor-restore\nAl visitar el link del script en Github, tiene un readme con detalle de lo que hace el script y los requerimientos necesarios, la idea del script, es que sea posible realizar este tipo de recuperaciones fácilmente sin la necesidad de ser DBA en caso de que en la empresa no exista DBA o el DBA no esté disponible. Por tanto, los requerimientos son:\nEjecutar como usuario oracle Tener la instancia de Oracle operativa El Veeam Plugin para Oracle instalado y configurado desde la consola de Veeam (Paso inicial) Luego comenzamos descargando el script y darle permisos de ejecución:\nEjecutamos e ingresamos los datos que nos pide el script:\nDespués de ingresar \u0026quot; y\u0026quot;, creará las carpetas, archivos y archivos de password necesarios y luego preguntará si necesitamos configurar el plugin de veeam:\nLa configuración solicitará el método de autenticación, que puede ser por usuario o recovery token, en este caso usaremos la segunda opción y la generaremos desde la consola de Veeam:\nCopia el recovery token (dura 24 horas) y pégalo donde lo solicita el script y luego nos preguntará si necesitamos recuperar el Control File:\nDespués nos preguntará si sabemos o no el Backup ID de Veeam, si lo hacemos por defecto, el script ayudará a obtener el Backup ID\nAhora nos preguntará por el nombre del respaldo del control file, para obtenerlo es simple, hay dos opciones, si selecciona \u0026ldquo;n\u0026rdquo; el script buscará dentro del respaldo el AUTOBACKUP del control file, para evitar la búsqueda es más fácil ir a la instancia original y ejecutar lo siguiente:\nBuscar el nombre del backup que comience con c-\nPor último al copiar el nombre del respaldo del control file, lo pegas en el script y comenzará la preparación completa:\nY queda completamente preparada la instancia para recuperar desde Veeam Explorer con el mismo nombre y DBID, validamos que la instancia no esté en ejecución y vamos a Veeam Backup Server a realizar la recuperación con el Explorer:\nLa única diferencia que haremos aquí, es cambiar el servidor donde recuperaremos:\nEl servidor original era oraclem1 y vamos a recuperar la base de datos original al servidor oraclem2 y veremos la recuperación exitosa\nRecuperar la DB a otra instancia con el nombre y DBID distinto # Al igual que en el punto de \u0026ldquo;Recuperar la DB a la misma instancia original | Diferente Nombre DB\u0026rdquo; sólo debes hacer los mismos pasos pero solo cambiar el server de destino y el nombre de la base de datos que quieres que se recupere en la instancia destino y funcionará simplemente.\nPosts relacionados # Veeam Oracle RMAN Plugin Buenas Prácticas Veeam Plugin Oracle RMAN Solución Veeam Oracle Permission Denied Veeam Agent Linux - Oracle Linux / Exadata ","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/posts/veeam-explorer-oracle-rman/","section":"Blog","summary":"Una de las preguntas frecuentes que siempre estoy recibiendo es cómo realizar la recuperación de bases de datos con Veeam Explorer for Oracle, lo cual tiene distintas formas de realizar cuando se usa Veeam Oracle Plugin, que comúnmente se usa en instalaciones de RAC como también en instalaciones donde la base de datos Oracle es standalone. En particular este post es solo para realizar la instalación de Veeam Plugin desde la consola de Veeam Backup \u0026 Replication como también, revisaremos las opciones de recuperación cuando se realizan respaldos a través del Plugin de RMAN.","title":"Veeam Explorer Oracle RMAN","type":"posts"},{"content":"","date":"11 de julio de 2025","externalUrl":null,"permalink":"/es/tags/veeam-explorer/","section":"Etiquetas","summary":"","title":"Veeam-Explorer","type":"tags"},{"content":"","date":"11 julio 2025","externalUrl":null,"permalink":"/en/tags/veeam-explorer-for-oracle/","section":"Tags","summary":"","title":"Veeam-Explorer-for-Oracle","type":"tags"},{"content":"","date":"11 julio 2025","externalUrl":null,"permalink":"/en/tags/veeam-plugin/","section":"Tags","summary":"","title":"Veeam-Plugin","type":"tags"},{"content":"","date":"17 de diciembre de 2024","externalUrl":null,"permalink":"/es/tags/appliance/","section":"Etiquetas","summary":"","title":"Appliance","type":"tags"},{"content":"","date":"17 de diciembre de 2024","externalUrl":null,"permalink":"/es/tags/decoys/","section":"Etiquetas","summary":"","title":"Decoys","type":"tags"},{"content":"","date":"17 de diciembre de 2024","externalUrl":null,"permalink":"/es/tags/security/","section":"Etiquetas","summary":"","title":"Security","type":"tags"},{"content":"","date":"17 de diciembre de 2024","externalUrl":null,"permalink":"/es/tags/se%C3%B1uelos/","section":"Etiquetas","summary":"","title":"Señuelos","type":"tags"},{"content":" Siempre estamos buscando formas de proteger mejor nuestra infraestructura de protección de datos. Las investigaciones y evidencias recientes de ataques ransomware han demostrado algo clave: los atacantes están enfocando sus esfuerzos en comprometer y destruir las soluciones de backup. ¿Por qué? Simple: sin respaldos, las organizaciones tienen más probabilidad de pagar el rescate. Es aquí donde entra Veeam Decoys, un proyecto open source que he desarrollado hace un tiempo para ayudar a detectar movimientos laterales (TA0008) y descubrimientos de servicios (TA0007) en tu red interna.\nIntroducción # La realidad es que detectar soluciones de protección de datos en una red es relativamente sencillo. Los servicios utilizan puertos específicos y la documentación es pública. Para un atacante que ya tiene acceso con credenciales administrativas, es cuestión de tiempo encontrar y potencialmente comprometer estos sistemas críticos.\nPor esto, además de seguir la regla 3-2-1-1-0 e implementar inmutabilidad en tus respaldos, necesitas una capa adicional de detección temprana\nSolución Simple pero Efectiva # Lo que hace Veeam Decoys es crear \u0026ldquo;señuelos\u0026rdquo; que parecen servicios reales de Veeam. Por ejemplo, es como poner sensores de movimiento en tu casa, pero en este caso es en tu red Interna. Estos señuelos detectan si alguien o algun software está:\nEscaneando tu red buscando servidores o servicios de Veeam Intentando conectarse a la consola de Veeam Intentando conectarse a repositorios de backup Probando credenciales en servicios de administración remota, RDP, SSH, Netbios Realizando movimientos laterales en tu infraestructura Para que nos sirve? Simple, si el atacante esta buscando los servicios de Veeam, esta solucion, detectará los escaneos de la red hacia los servicios de Veeam y enviará notificaciones a través de:\nSyslog, enviando todos los logs a tu SIEM Notificaciones por E-Mail Asi podrás saber de forma temprana cuando el o los atacantes ya se encuentren en tu red, utilizando las tácticas de Mitre TA0007 y TA0008 para realizar la respectiva investigación o iniciar el plan de respuesta ante incidentes.\nServicios Simulados # Veeam Backup Server Veeam Hardened Repository Veeam Windows Repository Veeam Backup Enterprise Manager SSH Remote Desktop (RDP) Netbios Beneficios Clave # 1. Recursos Mínimos\n1 vCPU 2GB RAM 50GB almacenamiento Perfecto para despliegues múltiples 2. Implementación Flexible\nDespliegue en múltiples VLANs con una sola instancia Arquitectura distribuida para mayor cobertura Appliance desechable - fácil de reemplazar 3. Integración y Notificación\nEnvío de logs a SIEM vía Syslog Alertas por correo electrónico Compatible con herramientas de monitoreo existentes Arquitectura Simple y Distribuida # Arquitectura Simple: Ideal para empresas pequeñas y medianas:\nUn Veeam Decoy por VLAN crítica Integración centralizada con SIEM Monitoreo vía email Arquitectura Distribuida: Perfecta para empresas grandes\nMonitoreo jerárquico Múltiples Decoys por ubicación Señuelos estratégicamente distribuidos En la documentación encontrarás detalles de cada una de las arquitecturas.\nResultados # En multiples pruebas se pudo detectar rapidamente:\nEscaneos automáticos de red que no se tenia conocimiento Intentos de conexión desde equipos no autorizados Herramientas de inventario mal configuradas Movimientos laterales sospechosos Intentos de Inicio de Sesion en el Decoy de Consola de Veeam Descarga e Instalación # Appliance Virtual\nDescarga: https://dl.24xsiempre.com/DecoyV1.ova Tiempo de implementación: ~15 minutos Instalación Manual\nGitHub: https://github.com/VeeamHub/veeam-decoy Un solo comando para instalar Documentación # English: https://dl.24xsiempre.com/Decoy_Manual_EN.pdf\nEspañol: https://dl.24xsiempre.com/Decoy_Manual_ES.pdf\nPreguntas Frecuentes # P: ¿Impacta el rendimiento de mi infraestructura actual? R: No, los señuelos son extremadamente livianos y no interfieren con servicios productivos.\nP: ¿Necesito modificar mi infraestructura existente? R: No, Veeam Decoys opera de forma independiente.\nP: ¿Qué hago si detecto actividad sospechosa? R: La herramienta te permite iniciar tu proceso de respuesta a incidentes de forma temprana. Y se debe tratar de forma prioritaria.\nConclusión # En un entorno donde los ataques son cada vez más sofisticados, necesitamos ser proactivos en nuestra defensa. Veeam Decoys proporciona una capa adicional de seguridad, dándote visibilidad temprana de posibles amenazas a tu infraestructura de backup.\nPosts relacionados # Plan de Respuesta ante Incidentes con NIST 800-61, 800-53r5, Mitre ATT\u0026amp;CK y Veeam Veeam Hardened (Immutable) Repository JADI Scanner vScan Vulnerability Scanner 2.0 Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam ","date":"17 de diciembre de 2024","externalUrl":null,"permalink":"/es/posts/veeam-decoys-deteccion-temprana/","section":"Blog","summary":"Siempre estamos buscando formas de proteger mejor nuestra infraestructura de protección de datos. Las investigaciones y evidencias recientes de ataques ransomware han demostrado algo clave: los atacantes están enfocando sus esfuerzos en comprometer y destruir las soluciones de backup. ¿Por qué? Simple: sin respaldos, las organizaciones tienen más probabilidad de pagar el rescate. Es aquí donde entra Veeam Decoys, un proyecto open source que he desarrollado hace un tiempo para ayudar a detectar movimientos laterales (TA0008) y descubrimientos de servicios (TA0007) en tu red interna.","title":"Veeam Decoys - Detección Temprana","type":"posts"},{"content":"","date":"17 diciembre 2024","externalUrl":null,"permalink":"/en/tags/veeam-decoys/","section":"Tags","summary":"","title":"Veeam-Decoys","type":"tags"},{"content":"","date":"21 de junio de 2024","externalUrl":null,"permalink":"/es/tags/icewhale/","section":"Etiquetas","summary":"","title":"Icewhale","type":"tags"},{"content":"","date":"21 junio 2024","externalUrl":null,"permalink":"/en/categories/kubernetes-backup/","section":"Categories","summary":"","title":"Kubernetes Backup","type":"categories"},{"content":"","date":"21 de junio de 2024","externalUrl":null,"permalink":"/es/tags/proxmox/","section":"Etiquetas","summary":"","title":"Proxmox","type":"tags"},{"content":" De acuerdo con las últimas novedades de Veeam, donde se anunció el soporte para Proxmox Virtual Environment (VE) y antes de que se libere la actualización, comencé a revisar como armar un pequeño laboratorio para instalar Proxmox en máquinas físicas y evitar hacer nested virtualization en vSphere. En este post veremos que servidores estoy usando y como funciona esta solución.\nServidores # Buscando computadores en internet, encontré algunos post sobre las ventajas de utilizar ciertos Single Board Computers (SBC) para instalar hipervisores o sistemas operativos para utilizarlos como servidor, asi que terminé en la pagina de https://www.zimaspace.com/ revisando sus productos donde me pareció muy interesante el ZimaBlade que posee en resumen las siguientes características de ZimaBlade 7700:\nCPU: N3450 / J3455 / E3950 Quad Cores 1.1GHz / 1.5GHz / 1.6GHz base frequency 2.2 GHz / 2.3GHz / 2.0GHz Burst 2MB L2 cache RAM: 1x SODIMM Slot / Compatible with 16GB DDR3L Storage: eMMC 5.1 / 32 GB HDD: 2x SATA 6.0 Gb/s Ports LAN: 1x GbE LAN Port PCIe: 1x PCIe 2.0 x4 TDP: 6W / 10W Por otra parte para mejorar la performance y evitar cambiar los parametros de instalación de Proxmox VE sobre un eMMC, adquirí 3 tarjetas PCIe:\nM.2 NVME to PCIe 4.0/3.0 Proxmox VE # Despues de instalar proxmox enc ada una de los servidores, podemos obersar un muy buen funionamiento, configure el almacenamiento con mi storage actual via iSCSI y la performance va muy bien!.\nAsi que lo unico que faltaria seria el release de Veeam para Proxmox :)\nPosts relacionados # Veeam Backup for Red Hat Virtualization Veeam Citrix Hypervisor / Xenserver Protegiendo Oracle KVM con Veeam Veeam Hardened (Immutable) Repository ","date":"21 de junio de 2024","externalUrl":null,"permalink":"/es/posts/proxmox-lab-con-zimablade/","section":"Blog","summary":"De acuerdo con las últimas novedades de Veeam, donde se anunció el soporte para Proxmox Virtual Environment (VE) y antes de que se libere la actualización, comencé a revisar como armar un pequeño laboratorio para instalar Proxmox en máquinas físicas y evitar hacer nested virtualization en vSphere. En este post veremos que servidores estoy usando y como funciona esta solución.","title":"Proxmox Lab con ZimaBlade","type":"posts"},{"content":"","date":"21 junio 2024","externalUrl":null,"permalink":"/en/tags/proxmox-backup/","section":"Tags","summary":"","title":"Proxmox-Backup","type":"tags"},{"content":"","date":"21 de junio de 2024","externalUrl":null,"permalink":"/es/categories/respaldo-kubernetes/","section":"Categorías","summary":"","title":"Respaldo Kubernetes","type":"categories"},{"content":"","date":"21 de junio de 2024","externalUrl":null,"permalink":"/es/tags/respaldo-proxmox/","section":"Etiquetas","summary":"","title":"Respaldo-Proxmox","type":"tags"},{"content":"","date":"21 de junio de 2024","externalUrl":null,"permalink":"/es/tags/zimablade/","section":"Etiquetas","summary":"","title":"Zimablade","type":"tags"},{"content":"","date":"21 de junio de 2024","externalUrl":null,"permalink":"/es/tags/zimaboard/","section":"Etiquetas","summary":"","title":"Zimaboard","type":"tags"},{"content":"","date":"3 de abril de 2024","externalUrl":null,"permalink":"/es/tags/cbt/","section":"Etiquetas","summary":"","title":"Cbt","type":"tags"},{"content":"","date":"3 de abril de 2024","externalUrl":null,"permalink":"/es/categories/immutable/","section":"Categorías","summary":"","title":"Immutable","type":"categories"},{"content":"","date":"3 de abril de 2024","externalUrl":null,"permalink":"/es/tags/kvm/","section":"Etiquetas","summary":"","title":"Kvm","type":"tags"},{"content":"","date":"3 de abril de 2024","externalUrl":null,"permalink":"/es/tags/oracle-kvm/","section":"Etiquetas","summary":"","title":"Oracle-Kvm","type":"tags"},{"content":"","date":"3 de abril de 2024","externalUrl":null,"permalink":"/es/tags/ovirt/","section":"Etiquetas","summary":"","title":"Ovirt","type":"tags"},{"content":" En este post revisaremos la configuración de Veeam Backup \u0026amp; Replication y la integración con Oracle KVM para realizar la protección de las máquinas virtuales que se ejecutan en esta plataforma. Además veremos algunas características importantes en relación a los discos, tipos de discos en KVM y como crear los discos para obtener Changed Block Tracking en los respaldos incrementales.\nIntroducción # Hace muy poco Veeam ha liberado el soporte a un nuevo hipervisor, en este caso, Oracle KVM, el cual no es muy diferente de RedHat Enterprise Virtualization, por tanto, revisaremos la documentacion actualizada de Veeam para KVM u oVirt:\nhttps://helpcenter.veeam.com/docs/vbrhv/userguide/overview.html?ver=41 Instalación Plugin oVirt KVM Veeam # Descargamos desde nuestro portal de cliente o directamente desde la página web de veeam:\nhttps://www.veeam.com/kvm-backup-recovery.html?ad=homepage-workload-logo Y descomprimir archivo en el servidor de Veeam Backup \u0026amp; Replication. Luego ejecutar la instalación, si el servidor no cumple con los requisitos, aparecerá el siguiente mensaje:\nSolo clic en \u0026ldquo;OK\u0026rdquo; y realizará la instalación de los prerequisitos y pasará al asistente de instalación:\nAgregar Oracle KVM a Veeam Backup \u0026amp; Replication # Ingresar a la consola de Veeam Backup \u0026amp; Replication, luego en \u0026ldquo;Backup Infrastructure\u0026rdquo; clic derecho en \u0026ldquo;Managed Servers\u0026rdquo; para luego clic en \u0026ldquo;Add Server\u0026rdquo;:\nY seleccionamos \u0026ldquo;Oracle Linux KVM\u0026rdquo;, luego ingresaremos la direccion IP o fqdn el servidor de administración, Oracle Virtualization Manager:\nIngresamos las credenciales (importante agregarle el profile en este caso @internal):\nAceptamos y veremos que se agrego exitosamente:\nFinalizamos y el asistente nos preguntará:\nSeleccionamos \u0026ldquo;Yes\u0026rdquo; y se ejecutará el asistente para la creación del proxy:\nSeleccionamos el cluster KVM:\nIngresamos un nombre y seleccionamos el \u0026ldquo;Storage Domain\u0026rdquo;:\nLuego \u0026ldquo;next\u0026rdquo; y seleccionar la red donde se creará el proxy:\nEs posible usar DHCP o dirección IP Fija, en mi caso siempre uso fija:\nLuego seleccionamos un usuario existente o creamos uno para generarlo como usuario local en el proxy:\nPermitir el acceso a todos los repositorios o solo a alguno en particular:\nY mientras se espera que termine el proceso, podremos observar en la consola de Oracle KVM la creación del proxy:\ny finalizamos:\nRespaldo de VM en Oracle KVM # Ahora crearemos un job de Respaldo de las máquinas virtuales en Oracle KVM\nY veremos la ejecución correcta:\nAnteriormente seleccionamos una VM que tiene habiltiado el respaldo incremental desde Oracle KVM, para validar que se encuentra habilitado, solo es necesario revisar los discos creados en la VM:\nPor defecto cuando se crean los discos en las últimas versiones de oVIrt KVM, viene seleccionado \u0026ldquo;Enable Incremental Backup\u0026rdquo;, si existiesen VM que vienen de versiones anteriores de oVirt, y no tiene habiltada esa opción, al realizar la tarea de respaldo Veeam Backup mostrará:\nRecuperación # La recuperación de datos es igual a cualquier otro respaldo de Veeam Backup \u0026amp; Replication:\nPosts relacionados # Veeam Oracle RMAN Plugin Veeam Agent Linux - Oracle Linux / Exadata Veeam Oracle Weblogic Veeam Backup for Red Hat Virtualization ","date":"3 de abril de 2024","externalUrl":null,"permalink":"/es/posts/protegiendo-oracle-kvm-con-veeam/","section":"Blog","summary":" En este post revisaremos la configuración de Veeam Backup \u0026 Replication y la integración con Oracle KVM para realizar la protección de las máquinas virtuales que se ejecutan en esta plataforma. Además veremos algunas características importantes en relación a los discos, tipos de discos en KVM y como crear los discos para obtener Changed Block Tracking en los respaldos incrementales.\n","title":"Protegiendo Oracle KVM con Veeam","type":"posts"},{"content":"","date":"3 de abril de 2024","externalUrl":null,"permalink":"/es/tags/qcow2/","section":"Etiquetas","summary":"","title":"Qcow2","type":"tags"},{"content":"","date":"3 de abril de 2024","externalUrl":null,"permalink":"/es/tags/qemu/","section":"Etiquetas","summary":"","title":"Qemu","type":"tags"},{"content":"","date":"18 marzo 2024","externalUrl":null,"permalink":"/en/tags/kubernetes-backup/","section":"Tags","summary":"","title":"Kubernetes-Backup","type":"tags"},{"content":"","date":"31 de enero de 2024","externalUrl":null,"permalink":"/es/tags/controles-de-seguridad-nist-800-53r5/","section":"Etiquetas","summary":"","title":"Controles-De-Seguridad-Nist-800-53R5","type":"tags"},{"content":"","date":"31 enero 2024","externalUrl":null,"permalink":"/en/tags/disaster-recovery-with-veeam/","section":"Tags","summary":"","title":"Disaster-Recovery-With-Veeam","type":"tags"},{"content":"","date":"31 de enero de 2024","externalUrl":null,"permalink":"/es/tags/estrategias-de-seguridad-mitre-attampck/","section":"Etiquetas","summary":"","title":"Estrategias-De-Seguridad-Mitre-Att\u0026Amp;Ck","type":"tags"},{"content":"","date":"31 enero 2024","externalUrl":null,"permalink":"/en/tags/incident-response-plan/","section":"Tags","summary":"","title":"Incident-Response-Plan","type":"tags"},{"content":"","date":"31 enero 2024","externalUrl":null,"permalink":"/en/tags/mitre-attampck-security-strategies/","section":"Tags","summary":"","title":"Mitre-Att\u0026Amp;Ck-Security-Strategies","type":"tags"},{"content":"","date":"31 enero 2024","externalUrl":null,"permalink":"/en/tags/nist-800-53r5-security-controls/","section":"Tags","summary":"","title":"Nist-800-53R5-Security-Controls","type":"tags"},{"content":"","date":"31 enero 2024","externalUrl":null,"permalink":"/en/tags/nist-800-61-incident-response/","section":"Tags","summary":"","title":"Nist-800-61-Incident-Response","type":"tags"},{"content":"","date":"31 de enero de 2024","externalUrl":null,"permalink":"/es/tags/nist-800-61-respuesta-a-incidentes/","section":"Etiquetas","summary":"","title":"Nist-800-61-Respuesta-a-Incidentes","type":"tags"},{"content":" En el panorama actual de seguridad informática, estar preparado para los incidentes es tan crucial como prevenirlos. Las normativas NIST 800-61 y 800-53r5, junto con la matriz enterprise de Mitre ATT\u0026amp;CK, proporcionan pautas sólidas para crear un plan de respuesta ante incidentes efectivo. En este post, revisaremos la importancia de estos marcos y cómo la Plataforma de Veeam es un aliado estratégico en la respuesta a incidentes.\nIntroducción # Hoy en dia, las amenazas informáticas evolucionan a un ritmo sin precedentes, la preparación y capacidad de respuesta ante incidentes de seguridad se convierten en pilares fundamentales para la protección de servicios informáticos. La implementación de un plan de respuesta ante incidentes robusto y efectivo es más que una medida preventiva; es una necesidad para asegurar la continuidad y la integridad del negocio u organización. En este contexto, las directrices establecidas por el NIST, a través de sus publicaciones 800-61 y 800-53r5, junto con la matriz de tácticas, técnicas y procedimientos (TTP) del Mitre ATT\u0026amp;CK, ofrecen un marco sólido para desarrollar, implementar y gestionar la respuesta ante incidentes de seguridad informática.\nProfundizaremos en la importancia de contar con un plan de respuesta ante incidentes bien estructurado, basado en los principios y prácticas recomendadas por NIST 800-61, la guía para la respuesta ante incidentes, y NIST 800-53r5, el catálogo de controles de seguridad y privacidad. Además, revisaremos como el framework Mitre ATT\u0026amp;CK puede enriquecer este plan, proporcionando una perspectiva detallada sobre las tácticas y técnicas empleadas por los adversarios o atacantes, lo que permite a las organizaciones anticiparse y mitigar de manera más efectiva los ataques.\nEn este escenario, la plataforma de Veeam emerge como un componente crítico, ofreciendo herramientas avanzadas para la recuperación rápida de datos y la continuidad del negocio frente a incidentes de seguridad. La capacidad de Veeam para proporcionar una recuperación rápida y fiable de datos desde ambientes inmutables se presenta como una contramedida robusta hacia diversas formas de amenazas, incluido el ransomware, asegurando que la integridad y disponibilidad de los datos críticos se mantengan intactos.\nLa Importancia de un Plan de Respuesta ante Incidentes # La creación y mantenimiento de un plan de respuesta ante incidentes, aparte o incluido en una DRP, es crucial en la gestión de la seguridad informática. Este plan no solo ayuda a las organizaciones a manejar y recuperarse de incidentes, sino que también juega un papel vital en la prevención de futuras brechas de seguridad.\nPrevención y Preparación: Pilares de la Seguridad Informática # Mitigación de Riesgos: Un plan de respuesta efectivo ayuda a identificar y abordar vulnerabilidades antes de que sean explotadas.\nReducción del Impacto de los Incidentes: Al tener un plan en su lugar, las organizaciones pueden actuar rápidamente para contener y mitigar el daño, reduciendo así el impacto general del incidente.\nCumplimiento Normativo: Muchas regulaciones y estándares de la industria exigen que las organizaciones tengan un plan de respuesta ante incidentes, haciendo que su desarrollo y mantenimiento sean también una cuestión de cumplimiento legal.\nElementos Clave para un Plan Efectivo # Comunicación: Establecer canales de comunicación efectivos tanto internos como externos, incluyendo notificaciones a partes afectadas y autoridades reguladoras.\nFormación y Educación del Personal: La capacitación regular del personal en procedimientos de respuesta ante incidentes es fundamental para asegurar una respuesta rápida y eficiente.\nSimulacros y Pruebas: Realizar ejercicios de simulación de incidentes ayuda a identificar áreas de mejora y garantiza que el equipo esté preparado para responder en un escenario real.\nAdaptabilidad y Mejora Continua # Un plan de respuesta ante incidentes no debe ser estático. Las amenazas informáticas evolucionan constantemente, y el plan debe adaptarse para abordar nuevas tácticas y técnicas de ataque.\nRevisión y Actualización Regular: Es esencial revisar y actualizar el plan de respuesta ante incidentes regularmente, especialmente después de un incidente real o un cambio significativo en el entorno de TI o en el panorama de amenazas.\nIntegración de Nuevas Tecnologías y Estrategias: La adopción de nuevas tecnologías y estrategias, como la inteligencia artificial para la detección de amenazas o soluciones avanzadas de respaldo y recuperación, puede mejorar significativamente la eficacia del plan.\nNIST 800-61: Guía para la Respuesta ante Incidentes # El NIST Special Publication 800-61, \u0026ldquo;Computer Security Incident Handling Guide\u0026rdquo;, es un documento clave en la gestión de la seguridad informática. Proporciona un marco detallado para establecer un plan de respuesta efectivo ante incidentes de seguridad informática.\nPreparación # Esta fase es fundamental para establecer un plan de respuesta ante incidentes eficaz. Incluye:\nCreación de un Equipo de Respuesta ante Incidentes (CSIRT): Formación de un equipo especializado con roles y responsabilidades definidas.\nDesarrollo de Políticas y Procedimientos: Elaborar políticas claras y procedimientos para la gestión de incidentes, incluyendo clasificación de incidentes y protocolos de respuesta.\nConfiguración de Herramientas y Tecnologías: Implementar y configurar herramientas adecuadas para la detección y análisis de incidentes, como sistemas de detección de intrusiones y software de gestión de incidentes.\nFormación: Capacitar al personal en prácticas de seguridad y respuesta ante incidentes.\nDetección y Análisis # Esta etapa se enfoca en identificar y analizar posibles incidentes:\nMonitoreo y Detección: Utilizar herramientas de monitoreo para identificar actividades sospechosas o anómalas que puedan indicar un incidente.\nAnálisis de Incidentes: Determinar la naturaleza y alcance del incidente. Esto incluye identificar el tipo de incidente, los sistemas afectados, y la posible causa.\nPriorización: Basar la respuesta en la criticidad del incidente, su impacto y urgencia.\nContención, Erradicación y Recuperación # En esta fase, se toman medidas para controlar y remediar el incidente:\nContención: Implementar estrategias de contención a corto y largo plazo para limitar el alcance del incidente.\nErradicación: Eliminar los componentes del incidente, como malware o accesos no autorizados.\nRecuperación: Restaurar los sistemas a su estado normal y asegurarse de que no haya resquicios de seguridad a traves de la Plataforma de Veeam.\nPost-Incidente # Después de un incidente, es vital realizar actividades de seguimiento:\nAnálisis Post-Incidente: Revisar y analizar cómo se manejó el incidente para identificar que se aprendió y mejorar las prácticas de respuesta.\nInformes y Documentación: Elaborar informes detallados sobre el incidente, incluyendo las acciones tomadas y recomendaciones para prevenir incidentes futuros.\nMejora Continua: Actualizar los planes de respuesta y las políticas de seguridad en base a las lecciones aprendidas.\nNIST 800-53r5: Controles de Seguridad y Privacidad # El NIST 800-53, Revision 5, \u0026ldquo;Security and Privacy Controls for Information Systems and Organizations\u0026rdquo;, es un estándar integral que proporciona un conjunto de controles de seguridad y privacidad para proteger los sistemas y las organizaciones contra una amplia gama de amenazas informáticas. Su relevancia en la creación de un plan de respuesta ante incidentes es fundamental.\nEnfoque en la Protección y Resiliencia # Controles de Seguridad: NIST 800-53r5 establece una serie de controles de seguridad que abarcan áreas como la protección de la información, la identidad y el acceso, la detección de intrusiones, y la recuperación de desastres. Estos controles están diseñados para proteger los sistemas y datos críticos de las amenazas informáticas.\nControles de Privacidad: Además de los controles de seguridad, este estándar también incluye controles específicos de privacidad para proteger la información personal y garantizar la conformidad con las leyes y regulaciones de privacidad.\nResiliencia Informática: NIST 800-53r5 pone un énfasis particular en la resiliencia, es decir, la capacidad de una organización para anticipar, resistir, recuperarse y adaptarse a eventos adversos, incluyendo ciberataques.\nAdaptación y Personalización de Controles # Posibilidad de Elegir: NIST 800-53r5 permite a las organizaciones seleccionar y personalizar controles basándose en su evaluación de riesgos, requisitos legales y regulatorios, y necesidades empresariales específicas.\nBasado en Riesgos: Este enfoque garantiza que los controles implementados sean proporcionales a los riesgos y amenazas que enfrenta la organización.\nIntegración con Planes de Respuesta ante Incidentes # Controles Preventivos y Reactivos: Los controles establecidos en NIST 800-53r5 no solo sirven para prevenir incidentes, sino que también juegan un papel crucial en la fase de respuesta. Por ejemplo, los controles de detección de intrusiones facilitan la identificación rápida de incidentes.\nSoporte en la Recuperación: Los controles relacionados con la recuperación de desastres y la continuidad del negocio son esenciales para restaurar los sistemas y servicios afectados por un incidente.\nMejora Continua y Cumplimiento Normativo # Cumplimiento y Evaluación: NIST 800-53r5 es una herramienta valiosa para evaluar el cumplimiento de las organizaciones con respecto a diversas regulaciones de seguridad informática.\nMejora Continua: La implementación de estos controles debe ser parte de un proceso de mejora continua, donde las organizaciones revisan y actualizan regularmente sus controles de seguridad y privacidad para adaptarse a las cambiantes amenazas informáticas.\nMitre ATT\u0026amp;CK: Entendiendo al Adversario # la matriz Mitre ATT\u0026amp;CK (Adversarial Tactics, Techniques, and Common Knowledge) es una herramienta esencial para comprender las tácticas y técnicas utilizadas por los adversarios informáticos. Este marco proporciona información detallada sobre las diversas formas en que los atacantes pueden penetrar, explotar y comprometer sistemas y redes.\nCada matriz de Mitre ATT\u0026amp;CK se divide en tácticas, que son los objetivos que los adversarios buscan alcanzar, las técnicas y subtecnicas o procedimientos que son los métodos que utilizan para lograr esos objetivos. Por ejemplo, en la matriz empresarial existen las siguientes tácticas:\nReconocimiento: El adversario intenta recopilar información que pueda utilizar para planificar futuras operaciones\nDesarrollo de Recursos: El adversario está tratando de establecer los recursos que puede utilizar para apoyar las operaciones.\nAcceso Inicial: Cómo los adversarios ingresan a un sistema o red.\nEjecución: Métodos para ejecutar código malicioso.\nPersistencia: Técnicas para mantener su presencia en un sistema comprometido.\nEscalación de Privilegios: Estrategias para ganar mayores privilegios en un sistema.\nEvasión de Defensas: Técnicas para evitar ser detectados.\nAcceso Credenciales: El adversario intenta robar nombres de cuentas y contraseñas.\nDescubrimiento: El adversario está tratando de averiguar su entorno.\nMovimiento Lateral: El adversario está tratando de moverse a través de su entorno.\nRecolección de Datos: El adversario intenta recopilar datos de interés para su objetivo\nComando y Control: El adversario intenta comunicarse con los sistemas comprometidos para controlarlos.\nExfiltración de Datos: Métodos para robar datos.\nImpacto: El adversario intenta manipular, interrumpir o destruir sus sistemas y datos.\nAplicación en la Respuesta a Incidentes # Entender las tácticas y técnicas del Mitre ATT\u0026amp;CK es clave para desarrollar estrategias de respuesta y mitigación efectivas:\nSimulaciones y Entrenamientos: Utilizar los escenarios del Mitre ATT\u0026amp;CK para realizar ejercicios de simulación y entrenar al personal en la identificación y respuesta a amenazas específicas.\nMejora de Estrategias de Seguridad: Las organizaciones pueden usar esta información para mejorar sus defensas, adaptando sus herramientas y procesos de seguridad para abordar técnicas específicas utilizadas por los atacantes.\nAnálisis Forense y de Causa Raíz: En caso de un incidente, el conocimiento de las técnicas específicas del Mitre ATT\u0026amp;CK puede ayudar en el análisis forense y en la identificación de la causa raíz del ataque.\nIntegración con Otras Normativas y Marcos # Complemento a NIST 800-61 y 800-53r5: Mientras NIST proporciona el marco para desarrollar un programa de seguridad y respuesta a incidentes, Mitre ATT\u0026amp;CK ofrece una visión detallada de las tácticas y técnicas que los adversarios pueden emplear, permitiendo así una preparación y respuesta más específica y efectiva.\nPlataforma Veeam # La plataforma de Veeam es una solución integral en la estrategia de respuesta a incidentes, proporcionando una línea de defensa clave contra las amenazas informáticas.\nProtección y Recuperación de Datos # Respaldo Confiable: Veeam ofrece soluciones robustas de respaldos, asegurando que los datos estén protegidos y puedan ser recuperados en caso de pérdida o corrupción.\nRecuperación Rápida: La capacidad de Veeam para restaurar rápidamente sistemas y datos es esencial para minimizar el tiempo de inactividad después de un incidente, lo que es crítico para la continuidad del negocio.\nSeguridad de los Respaldos # Inmunidad contra Ransomware: Veeam proporciona características que ayudan a proteger los respaldos contra el ransomware, asegurando que los datos de respaldo permanezcan intactos y seguros.\nAislamiento de Datos (Air-Gap): La capacidad de Veeam para crear respaldos aislados (air-gapped) es vital para proteger los datos contra ataques que buscan corromper o eliminar respaldos de datos.\nCumplimiento y Conformidad # Cumplimiento con Normativas: Veeam ayuda a las organizaciones a cumplir con diversas regulaciones de seguridad de datos al proporcionar una solución de copia de seguridad y recuperación de datos segura y confiable.\nAuditorías y Reportes: Veeam facilita la generación de informes y auditorías, permitiendo a las organizaciones documentar sus esfuerzos de protección de datos y respuesta ante incidentes.\nAutomatización y Eficiencia # Automatización de Procesos: Veeam automatiza muchos aspectos de la copia de seguridad y la recuperación, lo que reduce el margen de error humano y aumenta la eficiencia en la respuesta a incidentes.\nOrquestación de la Recuperación: La orquestación de recuperación de Veeam simplifica el proceso de restaurar servicios y aplicaciones críticas, siguiendo un orden predefinido para garantizar una recuperación coherente y eficaz.\nFlexibilidad y Escalabilidad # Adaptabilidad a Diversos Entornos: Veeam es compatible con una variedad de entornos de TI, incluyendo la nube, entornos virtuales y físicos, lo que lo hace adaptable a las necesidades de diferentes organizaciones.\nEscalabilidad: A medida que las organizaciones crecen, Veeam puede escalar para satisfacer las crecientes demandas de protección de datos y recuperación ante desastres.\nRecomendaciones # Al concluir este análisis sobre la importancia de un plan de respuesta ante incidentes basado en NIST 800-61, NIST 800-53r5 y Mitre ATT\u0026amp;CK, y la importancia de la Plataforma de Veeam, aquí presentamos algunas recomendaciones clave para las organizaciones que buscan fortalecer su seguridad informática:\nImplementar un Plan de Respuesta Integral: Desarrollar y mantener un plan de respuesta ante incidentes que incorpore las directrices de NIST 800-61 y 800-53r5. Este plan debe ser exhaustivo, incluyendo procedimientos claros para la detección, análisis, contención, erradicación y recuperación de incidentes.\nCapacitación Continua: Invertir en la formación regular de los empleados y las partes interesadas sobre las prácticas de seguridad informática. Esto incluye familiarizarse con las tácticas y técnicas descritas en el marco Mitre ATT\u0026amp;CK.\nEvaluación y Mejora Continua: Realizar auditorías y revisiones periódicas del plan de respuesta ante incidentes para identificar áreas de mejora. Adaptarse a las nuevas amenazas y cambios en el panorama de la seguridad informática.\nIntegrar Soluciones Avanzadas de Backup y Recuperación: Utilizar soluciones como Veeam Backup \u0026amp; Replication para garantizar una recuperación rápida y efectiva en caso de incidentes. Esto es crucial para minimizar el tiempo de inactividad y la pérdida de datos.\nSimulacros de Incidentes: Realizar ejercicios de simulación de incidentes regularmente para probar y mejorar la eficacia del plan de respuesta. Estos ejercicios deben reflejar escenarios realistas basados en las tácticas y técnicas del Mitre ATT\u0026amp;CK.\nColaboración y Compartir Información: Fomentar la colaboración entre equipos internos y con otras organizaciones. Compartir información sobre amenazas y mejores prácticas puede ayudar a mejorar las estrategias de defensa colectiva.\nEnfoque Proactivo en la Seguridad Informática: Adoptar un enfoque proactivo, no solo reactivo, hacia la seguridad informática. Esto incluye mantenerse actualizado sobre las últimas tendencias en amenazas informáticas y tecnologías de seguridad.\nRespuesta Legal y de Cumplimiento: Asegurarse de que el plan de respuesta ante incidentes esté alineado con los requisitos legales y de cumplimiento. Esto es crucial para manejar de manera efectiva las implicaciones legales y de reputación que pueden surgir de un incidente de seguridad.\nImplementando estas recomendaciones, las organizaciones pueden mejorar significativamente su capacidad para prevenir, detectar y responder a incidentes de seguridad informática, asegurando así la protección continua de sus activos críticos y la continuidad del negocio en un entorno digital cada vez más desafiante.\nPosts relacionados # Veeam Hardened (Immutable) Repository Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam Veeam Decoys - Detección Temprana JADI Scanner vScan Vulnerability Scanner 2.0 ¿Que Sistema Operativo es más Seguro? ","date":"31 de enero de 2024","externalUrl":null,"permalink":"/es/posts/plan-de-respuesta-ante-incidentes/","section":"Blog","summary":"Plan de respuesta a incidentes basado en NIST 800-61, NIST 800-53r5 y Mitre ATT\u0026CK con Veeam para protección contra ransomware y resiliencia.","title":"Plan de respuesta a incidentes con NIST y Veeam","type":"posts"},{"content":"","date":"31 de enero de 2024","externalUrl":null,"permalink":"/es/tags/plan-de-respuesta-ante-incidentes/","section":"Etiquetas","summary":"","title":"Plan-De-Respuesta-Ante-Incidentes","type":"tags"},{"content":"","date":"31 de enero de 2024","externalUrl":null,"permalink":"/es/tags/protecci%C3%B3n-contra-ransomware/","section":"Etiquetas","summary":"","title":"Protección-Contra-Ransomware","type":"tags"},{"content":"","date":"31 enero 2024","externalUrl":null,"permalink":"/en/tags/ransomware-protection/","section":"Tags","summary":"","title":"Ransomware-Protection","type":"tags"},{"content":"","date":"31 de enero de 2024","externalUrl":null,"permalink":"/es/tags/recuperaci%C3%B3n-ante-desastres-con-veeam/","section":"Etiquetas","summary":"","title":"Recuperación-Ante-Desastres-Con-Veeam","type":"tags"},{"content":"","date":"31 de enero de 2024","externalUrl":null,"permalink":"/es/tags/resiliencia/","section":"Etiquetas","summary":"","title":"Resiliencia","type":"tags"},{"content":"","date":"31 enero 2024","externalUrl":null,"permalink":"/en/tags/resiliency/","section":"Tags","summary":"","title":"Resiliency","type":"tags"},{"content":" En este post revisaremos los sistemas operativos más utilizados por las organizaciones en los ambientes de TI, ya sea en nube pública, centros de datos locales, haciendo la típica pregunta, que sistema operativo es más seguro?, Microsoft Windows, Linux, OpenBSD, FreeBSD? o desde otro punto de vista, cuales son las medidas de protección que se aplicarán a los sistemas operativos?, Solo basta con Firewall y Antivirus? Solo basta con deshabilitar el servicio SSH en ambientes Linux? Solo basta con no usar root?\nIntroducción # Hace un tiempo atrás y en los últimos VeeamON Tours de Latinoámerica, conversaba con clientes y compañeros de trabajo sobre la típica pregunta, ¿Qué sistema operativo es más seguro? algunos decían, siempre es más seguro Linux, otros decian Windows y por último otros optaban por OpenBSD (Uno de sus objetivos es ser el S.O más seguro) y FreeBSD, pero realmente importa el sistema operativo o lo que importa es la forma como se despliega y se protegen los sistemas operativos?, siempre hablando desde un punto de vista de la seguridad.\nPor lo general, siempre se habla de hacer \u0026ldquo;hardening\u0026rdquo; a los sistemas operativos, apuntando a una seguridad por defecto, pero ese \u0026ldquo;hardening\u0026rdquo; se va actualizando en el tiempo? Las personas que indican que Linux es más seguro, cuántas veces actualizan los servidores Linux desde que se encuentra alguna vulnerabilidad? Por lo general, en Latam y de acuerdo con mi experiencia, son muy pocas las organizaciones que sí mantienen actualizados sus servidores con sistema operativo Linux o BSD, pero otra parte no menor prefieren quedar expuestos a cualquier ataque basado en alguna vulnerabilidad de Linux / BSD o de alguna aplicación que preste servicios. Y ni hablar de los profesionales que no desean actualizar Windows por que no saben si va a funcionar la solución que tienen instalada o simple y llanamente tienen la idea de \u0026ldquo;a mi empresa no la van a atacar\u0026rdquo;.\nTu Organización está preparada para recibir un Ataque? # Es una tremenda pregunta, ya que no es fácil de responder, y en general, la repuesta es siempre No, ya que pueden existir muchos factores en las organizaciones que no permiten a las áreas de IT minimizar el riesgo, por ejemplo, alguno de los problemas más comunes que he visto:\nPresupuesto Aplicaciones Antiguas o Legadas Falta de Entrenamiento Falta de utilización de un Framework de Seguridad Falta de Controles en la Infraestructura IT Reutilización de Credenciales Falta de utilización de RBAC o Role based Access Control Falta de documentación Entonces, con los ejemplos anteriores, se hace muy complejo prepararse ante un ataque, de hecho, solo es necesario hacer algun tipo de OSINT, para identificar ciertas organizaciones con sus respectivos servicios publicados (RDP, ILO, SQL, IDRAC, etc) en internet sin la seguridad necesaria.\nQue Framework de Seguridad utilizar para minimizar el Riesgo? # Como dato adicional, ya que al hablar de frameworks de seguridad es necesario un post independiente, el primer framework a utilizar en tu organizacion puede ser el Cyber Security Framework (CSF) ya sea la versión actualmente publicada 1.1 o la próxima que se encuentra en un borrador, 2.0, del Instituto Nacional de Estándares y Técnologias de USA ( NIST), donde, de acuerdo con las version 2.0, se encuentran 6 funciones principales:\nCon estas funciones, es posible implementar una estrategia necesaria, con el objetivo de minimizar el riesgo en ciberseguridad, para que en caso de un ataque, poder reaccionar oportunamente. Una muy buena recomendación en conjunto con CSF, es la utilización de la publicación especial SP 800-53r5 para la aplicación de los controles necesarios.\nCSF https://www.nist.gov/cyberframework SP 800-53r5 https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final Que Sistema Operativo elegir para los Servicios a Prestar? # Volviendo al tema principal, ¿Que Sistema Operativo es más Seguro?, lo primero que debemos revisar, es cual o cuales servicios vamos a instalar o utilizar en nuestro servidor, luego, dependiendo de la organización o requisitos del fabricante, revisar si la implementación de la solución puede ser posible en nube nativa, hibrida, on premises, kubernetes, serverless con el objetivo de buscar la mejor forma de brindar alta disponibilidad.\nAhora respecto a la decisión con que sistema operativo trabajar, ya sea definido por el software que se ejecutará en el servidor o ya sea por directrices de la organización, lo primero que debemos revisar es si vamos a exponer servicios hacia internet, que tipo de servicios, autenticación de los usuarios internos o externos, para conseguir cuáles seran las soluciones de seguridad que nos permitirán brindar protección al menos básica para proveer los servicios.\nYa teniendo conocimientos de los servicios a prestar, hay que definir SIEMPRE, cual sera la protección de estos servicios o sistema operativo, por supuesto, con una estrategia correcta de respaldo de los datos, que nos permita realizar la recuperación de los datos de distintas formas, para que en caso de ataque, tener múltiples opciones de recuperación de acuerdo con la necesidad de la continuidad del negocio.\nY por último, revisando los requerimientos del software o plataforma a instalar en el servidor, se podrá tomar la decisión sea favorable para la solución y se encuentre directamente relacionado con las políticas de seguridad de la organización o empresa.\nEntonces, ¿Que Sistema Operativo es más Seguro? # La respuesta es bastante simple, el sistema operativo más seguro, siempre será, el que cumpla con una correcta implementación desde un punto de vista de seguridad integral e utilización segura, cumpliendo con controles de seguridad, ejemplo 800-53r5, aplicación de políticas de seguridad locales, monitoreo, utilización de distintos sistemas de seguridad de red y local, por tanto, no solo se trata del sistema operativo, se trata de todos los procedimientos, herramientas, políticas de seguridad que acompañan la gestión y utilización de los servicios a utilizar.\nTodos los sistemas operativos, inclusive aplicaciones, tienen o tendrán vulnerabilidades de seguridad, ya que siempre existiran personas u organizaciones dedicadas a encontrar algun tipo de vulnerabilidad, ya sea por hobby, creación de malware o una hermosa investigacion.\nPor tanto, una de las opciones a considerar siempre es revisar la capacidad o frecuencia de las actualizaciones de seguridad o características de los diferentes fabricantes de los sistemas operativos y aplicaciones, por ejemplo, en caso de algunas soluciones basadas en kubernetes, la frecuencia de actualizacion de las imagenes utilizadas y la aplicación como tal, son continuamente mejoradas o actualizadas para minimizar el riesgo de existir alguna vulnerabilidad.\nEs por ello, que no es un tema del tipo de sistema operativo, por ejemplo, Linux es mas seguro que Windows?, Windows es mas Seguro que Linux?, MacOS es mas seguro que los anteriores? OpenBSD, es el sistema más seguro?. Como hemos visto, ninguno es más seguro que otro, ya que es solo buscar en las distintas bases de datos de Vulnerabilidades:\nhttps://www.cve.org/ https://nvd.nist.gov/vuln/search https://packetstormsecurity.com/ Y en los links anteriores, no solo se encontrarán las vulnerabilidades de los sistemas operativos, tambien de las aplicaciones que pueden ejecutarse en servidores o estaciones de trabajo.\nMonitoreo y Protección # Cada vez que se genere un nuevo servidor, ya sea virtual o físico, DEBE, tener asociado un mecanismo de monitoreo de servicios y comportamiento de los diferentes recursos que estará utilizando el servidor y OBLIGATORIAMENTE el esquema de actualizacion de parches y la protección de los datos, por supuesto con Veeam :), ya que como vimos anteriormente, al utilizar framework de seguridad, es de suma importancia contar con la información de cuales serán los planes de recuperación ante desastres y la definición de RTO / RPO para cumplir con los tiempos necesarios.\nPor que es importante el Monitoreo? más allá del monitoreo de los servicios, los sistemas de monitoreo actuales, como Veeam ONE, permiten tener información del comportamiento de las máquinas virtuales, es decir, es posible identificar el consumo de IOps, CPU, que podría ser sospechoso en un dia que no sea de carga mensual, con esto, al tener la información necesaria sera posible aplicar las acciones correctiva manualmente o automáticamente.\nPor ejemplo para las vulnerabilidades de día cero u 0day, es de suma importancia monitorear los sistemas o servicios para saber si estas vulnerabilidades se están explotando o el servidor a comenzado con un comportamiento anormal.\nActualizaciones # Si o si mantener una política estricta de actualizaciones, independiente, del sistema operativo usado, ya que la primera forma de ataque es aprovecharse de las vulnerabilidades existentes de los sistemas operativos por ejemplo la ejecución remota de comandos, RCE, que últimamente se ha estado utilizando en versiones de hipervisores VMware. Por otra parte, al tener actualizados los sistemas operativos, también es de suma importancia mantener actualizadas las dependencias y las aplicaciones que estarán prestando servicios, como por ejemplo, las soluciones de Atlassian que últimamente se han encontrado múltiple vulnerabilidades criticas.\nGuías Técnicas de Aplicación de Seguridad # Una de las prácticas ampliamente utilizadas es la aplicación de las guías DISA STIG, OpenSCAP, ya sea para sistemas operativos o para aplicaciones que se ejecutarán sobre los servidores. Es muy importante revisar estas guías, ya que se podría implementar completamente las recomendaciones o seleccionar las recomendaciones de seguridad que indican, por ejemplo si necesitas realizar la aplicación de controles de seguridad para Microsoft Windows Server 2022 y de Ubuntu 20.04 solo debes visitar:\nhttps://public.cyber.mil/stigs/downloads/ https://ncp.nist.gov/repository Por mencionar algunos, existen más, que dependiendo de la necesidad, será posible aplicar los controles necesarios de acuerdo a la necesidad o negocio de tu organización.\nMalas Prácticas de Seguridad en Sistemas Operativos o Servicios # Algunas que he visto reiteradamente:\nUsar Administrador o root para instalar aplicaciones Usar las mismas credenciales de acceso por múltiples usuarios Ej: administrator@vsphere.local No utilizar o habilitar MFA No tener una política estricta de cambio de contraseñas y complejidad. No contar con una política de respaldos y pruebas de recuperación. No centralizar logs o eventos de sistemas operativos y aplicaciones Guardar las contraseñas en un archivo Excel / TXT Poca o nada de documentación de los sistemas o arquitecturas. Utilización solo de Antivirus No utilización de cifrado Buenas Prácticas de Seguridad en Sistemas Operativos o Servicios # Algunas que deben ser utilizadas:\nUsar siempre cuentas de servicio para las aplicaciones Segmentar y aplicar RBAc a las cuentas por usuario Deshabilitar cuentas por defecto o sin uso Habilitar MFA donde sea posible y guardar los códigos de respaldo. Aplicar politica de Cambio de Contraseñas Respaldar todos los datos donde sea posible y probar la recuperacion cada cierto tiempo Monitorear y guardar logs de todos los sistemas criticos Utilizar Gestores de Contraseñas Empresariales Documentar todas las arquitecturas y procesos necesarios. Utilización de soluciones de seguridad en cada uno de los sistemas operativos Cifrar comunicaciones y Respaldos Recomendaciones # La primera regla obligatoria siempre es mantener actualizados todos los sistemas operativos y servicios que se instalen en el servidor, además del correspondiente monitoreo ya sea desde el punto de vista de disponibilidad de servicios como tambien de todos los registros de auditoria para identificar comportamientos extraños a la solución y aplicar las medidas correctivas.\nPor supuesto instalar soluciones de seguridad en los distintos sistemas operativos (no solo Windows) para obtener una total visión y monitoreo desde el punto de vista de seguridad.\nUtilizar siempre el principio de menor privilegio y no usar metodos de autenticación débiles, si el servicio no está siendo utilizado, deshabilitarlo o simplemente desintalar el servicio completamente.\nY por supuesto, la utilización de la Plataforma de Veeam para proteger todos tus datos en la organización, ya sea en tu centro de datos, Nube Pública, estaciones de trabajo, validando la recuperabilidad de forma automatizada, analizando y búscando malware en los respaldos para luego crear y documentar automatizadamente los Planes de Recuperación ante Desastres, DRP, con el objetivo de la recuperación de la organización con los datos de manera limpia y sin reinfección.\nPosts relacionados # Veeam Hardened (Immutable) Repository Veeam Immutable Repository con Red Hat Enterprise Linux Plan de Respuesta ante Incidentes con NIST 800-61, 800-53r5, Mitre ATT\u0026amp;CK y Veeam Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam ","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/posts/que-sistema-operativo-es-mas-seguro/","section":"Blog","summary":"En este post revisaremos los sistemas operativos más utilizados por las organizaciones en los ambientes de TI, ya sea en nube pública, centros de datos locales, haciendo la típica pregunta, que sistema operativo es más seguro?, Microsoft Windows, Linux, OpenBSD, FreeBSD? o desde otro punto de vista, cuales son las medidas de protección que se aplicarán a los sistemas operativos?, Solo basta con Firewall y Antivirus? Solo basta con deshabilitar el servicio SSH en ambientes Linux? Solo basta con no usar root?","title":"¿Que Sistema Operativo es más Seguro?","type":"posts"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/actualizaciones/","section":"Etiquetas","summary":"","title":"Actualizaciones","type":"tags"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/drp/","section":"Etiquetas","summary":"","title":"Drp","type":"tags"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/freebsd/","section":"Etiquetas","summary":"","title":"Freebsd","type":"tags"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/categories/kubernetes/","section":"Categorías","summary":"","title":"Kubernetes","type":"categories"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/linux/","section":"Etiquetas","summary":"","title":"Linux","type":"tags"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/openbsd/","section":"Etiquetas","summary":"","title":"Openbsd","type":"tags"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/rbac/","section":"Etiquetas","summary":"","title":"RBAC","type":"tags"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/secure/","section":"Etiquetas","summary":"","title":"Secure","type":"tags"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/sistema-operativo/","section":"Etiquetas","summary":"","title":"Sistema-Operativo","type":"tags"},{"content":"","date":"3 de noviembre de 2023","externalUrl":null,"permalink":"/es/tags/updates/","section":"Etiquetas","summary":"","title":"Updates","type":"tags"},{"content":"","date":"25 de abril de 2023","externalUrl":null,"permalink":"/es/tags/active-directory-kasten/","section":"Etiquetas","summary":"","title":"Active-Directory-Kasten","type":"tags"},{"content":" En este post, revisaremos como realizar la configuración de Kasten K10 instalado a través del Operador para Red Hat Openshift con el objetivo de integrar la autenticación de Microsoft Active Directory para acceder a la consola de K10 con Dex.\nDocumentación # Como siempre, debemos visitar la documentación oficial de las soluciones que utilizaremos para este post:\nKasten K10 https://docs.kasten.io/latest/install/openshift/operator.html Kasten Auth https://docs.kasten.io/latest/access/authentication.html Red Hat OpenShift https://docs.openshift.com/ Incluido en Kasten, Dex https://dexidp.io/docs/ Una de las integraciones más utilizadas en entornos empresariales para la autenticación y acceso centralizado es Microsoft Active Directory con distintas soluciones. En este caso revisaremos el acceso a la consola de Kasten K10 instalado desde el Operador con su respectiva \u0026ldquo;route\u0026rdquo;.\nAl ser instalado desde el operador, los cambios deben ser realizados en el archivo de configuración yaml que se puede acceder desde la consola de Openshift:\nConfiguración Autenticación Active Directory # Siempre es bueno usar grupos de usuarios para la gestión de acceso a diferentes plataformas, en este caso, también utilizaremos grupos de usuarios, lo primero a crear es un Grupo de Usuarios en Active Directory con un nombre relacionados los Cluster Roles de Kasten K10:\nAgregaremos los usuarios que necesiten acceso a Kasten K10 y procederemos a generar los Cluster Role Binding y Role Binding necesario por Kasten K10 para que se puedan autenticar los usuarios pertenecientes al grupo \u0026ldquo;k10admins\u0026rdquo;. El primer ClusterRoleBinding necesario es el siguiente:\nkubectl create clusterrolebinding k10-ad-oc --clusterrole=k10-admin --group=k10admins ```bash El siguiente RoleBinding se realiza en el namespace de \u0026#34;kasten-io\u0026#34; con el rol de k10-ns-admin; ```bash kubectl create rolebinding k10-ad-ns --role=k10-ns-admin \\ --namespace=kasten-io \\ --group=k10admins ```bash Ya con estos requerimientos creados procederemos a configurar Kasten K10. ## Configuración Kasten K10 y Microsoft Active Directory Solo debemos entrar en la configuración del Operador de Red Hat OpenShift y luego en la instancia de K10 instalada para acceder al archivo yaml: Aqui será muy importante que seamos cuidadosos al modificar este archivo, ya que, si alguna de las configuración o condiciones no se cumple, OpenShift, volverá a aplicar el archivo yaml que funcionaba correctamente anteriormente y no se verán los cambios reflejados. Dentro del archivo yaml, existe una variable \u0026#34;auth\u0026#34; con sus respectivas configuraciones, se debe agregar después de la última configuración o reemplazar el bloque completo con: ```bash ldap: enabled: true bindPW: \u0026#39;SuperDuperPassword\u0026#39; usernameClaim: email groupSearch: baseDN: \u0026#39;DC=24xsiempre,DC=cl\u0026#39; filter: (objectClass=group) nameAttr: cn userMatchers: - groupAttr: member userAttr: distinguishedName bindDN: \u0026#39;CN=administrator,CN=Users,DC=24xsiempre,DC=cl\u0026#39; host: \u0026#39;ad.24xsiempre.cl:389\u0026#39; usernamePrefix: \u0026#39;-\u0026#39; insecureNoSSL: true groupnameClaim: groups userSearch: baseDN: \u0026#39;DC=24xsiempre,DC=cl\u0026#39; emailAttr: userPrincipalName filter: (objectClass=user) idAttr: sAMAccountName nameAttr: givenName username: sAMAccountName restartPod: false insecureSkipVerifySSL: true startTLS: false usernamePrompt: Email Address secretName: \u0026#39;\u0026#39; dashboardURL: \u0026#39;http://k10-route-kasten-io.apps.oc.24xsiempre.cl/k10/\u0026#39; groupnamePrefix: \u0026#39;-\u0026#39; tokenAuth: enabled: false ```bash Como se observa en los datos anteriores, es necesario cambiar las siguientes varibales con los datos de tu entorno: - bindPW \\| Con la contraseña para autenticarse en AD o utilizar secret - baseDN \\| Con el dominio de tu entorno DC=24xsiempre,DC=cl - bindDN \\| Con el usuario que se autenticara en AD como servicio CN=administrator,CN=Users,DC=24xsiempre,DC=cl - host \\| DNS o IP de servidor AD - baseDN \\| Con el dominio de tu entorno DC=24xsiempre,DC=cl - dashboardURL \\| La ruta generada en OpenShift http://k10-route-kasten-io.apps.oc.24xsiempre.cl/k10/ Luego asegurarse de hacer clic en \u0026#34;Save\u0026#34; para luego validar la configuración. Aqui pueden ser dos formas, hacer un rollout restart o simplemente eliminar todos los pods de kasten y esperar que esten todos nuevamente en \u0026#34;Running\u0026#34;, para eliminar todos los pods de kasten-io y luego se generen automáticamente: ```bash kubectl delete pods -all -n kasten-io ```bash Luego de eso, acceder a la ruta de OpenShift creada y validar autenticación. ## Revisión de Logs En caso de algún problema con la autenticación hacia Microsoft Active Directory, es importante revisar los Logs de \u0026#34;Dex\u0026#34;, el cual es la interfaz que se conecta a Active Directory y busca los usuario asociados a los grupos que se autenticarán en la consola de Kasten K10, para ver los logs desde la consola de OpenShift, solo hay que entrar en \u0026#34;Workloads\u0026#34;, \u0026#34;Pods\u0026#34;, dentro del proyecto o namespace \u0026#34;kasten-io\u0026#34; y seleccionar el pod \u0026#34;auth-svc-\u0026#34; Luego clic en \u0026#34;Logs\u0026#34; y por último, al lado de \u0026#34;Log Streaming\u0026#34; seleccionar \u0026#34;dex\u0026#34; ## Búsqueda Atributos en Active Directory En caso de que aparezcan errores donde dex o la autenticación indique que no puede encontrar los usuario o grupos, es necesario validar la búsqueda de los atributos en el dominio, una de las herramientas más usadas en linux es \u0026#34;ldapsearch\u0026#34;, por ejemplo, en Ubuntu 22.04.2 se instala de la siguiente forma: ```bash sudo apt-get install ldap-utils ```text Para luego utilizar los comandos de ldapsearch y buscar correctamente los usuarios y grupos que necesitan ser configurados en la ruta de \u0026#34; **baseDN**\u0026#34;, por ejemplo con el siguiente comando, validaremos el atributo de \u0026#34;userPrincipalName\u0026#34; ```text ldapsearch -H \u0026#39;ldap://20.20.20.20\u0026#39; -D \u0026#39;veeam@24xsiempre.cl\u0026#39; -W -b \u0026#39;DC=24xsiempre,DC=cl\u0026#39; \u0026#39;SamAccountName=veeam\u0026#39; ```bash ## Usando Secret para Autenticarse con Active Directory En caso de entornos donde no se permita utilizar la contraseña directamente en los yaml, es posible configurar la contraseña con un secret donde el comando a utilizar para la creacion del secret es el siguiente: ```bash kubectl create secret generic k10-ad-secret-prod --from-literal=bindPW=SuperDuperPassword -n kasten-io ```bash Ya con la contraseña del usuario que se autenticada en Active Directory en el secret, solo nos falta configurar el yaml de la instancia K10 creada en el Operador de Kasten en Red Hat OpenShift: ```bash ldap: enabled: true usernameClaim: email groupSearch: baseDN: \u0026#39;DC=24xsiempre,DC=cl\u0026#39; filter: (objectClass=group) nameAttr: cn userMatchers: - groupAttr: member userAttr: distinguishedName bindDN: \u0026#39;CN=administrator,CN=Users,DC=24xsiempre,DC=cl\u0026#39; host: \u0026#39;ad.24xsiempre.cl:389\u0026#39; usernamePrefix: \u0026#39;-\u0026#39; insecureNoSSL: true groupnameClaim: groups userSearch: baseDN: \u0026#39;DC=24xsiempre,DC=cl\u0026#39; emailAttr: userPrincipalName filter: (objectClass=user) idAttr: sAMAccountName nameAttr: givenName username: sAMAccountName restartPod: false insecureSkipVerifySSL: true startTLS: false usernamePrompt: Email Address secretName: \u0026#39;\u0026#39; dashboardURL: \u0026#39;http://k10-route-kasten-io.apps.oc.24xsiempre.cl/k10/\u0026#39; groupnamePrefix: \u0026#39;-\u0026#39; bindPWSecretName: k10-ad-secret tokenAuth: enabled: false ```bash En la configuracion anterior se observa la variable: - bindPWSecretName Asociada con el nombre del secret que posee la contraseña del usuario para autenticarse. Ahora solo falta esperar que se reinicen los pods o eliminar todos los pods con el comando: ```bash kubectl delete pods --all -n kasten-io Y sera posible nuevamente autenticarse con Active Directory y Kasten K10\nPosts relacionados # Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1 Kasten K10 Authentik Red Hat OpenShift en vSphere con Kasten Como Instalar vSphere CSI Driver en RedHat OpenShift 4.x ","date":"25 de abril de 2023","externalUrl":null,"permalink":"/es/posts/como-integrar-active-directory-con-kasten-k10-y-openshift/","section":"Blog","summary":"En este post, revisaremos como realizar la configuración de Kasten K10 instalado a través del Operador para Red Hat Openshift con el objetivo de integrar la autenticación de Microsoft Active Directory para acceder a la consola de K10 con Dex.","title":"Como Integrar Active Directory con Kasten K10 y OpenShift","type":"posts"},{"content":"","date":"25 de abril de 2023","externalUrl":null,"permalink":"/es/categories/openshift/","section":"Categorías","summary":"","title":"Openshift","type":"categories"},{"content":"","date":"25 de abril de 2023","externalUrl":null,"permalink":"/es/tags/openshift/","section":"Etiquetas","summary":"","title":"OpenShift","type":"tags"},{"content":"","date":"25 de abril de 2023","externalUrl":null,"permalink":"/es/tags/openshift-active-directory/","section":"Etiquetas","summary":"","title":"Openshift-Active-Directory","type":"tags"},{"content":"","date":"25 de abril de 2023","externalUrl":null,"permalink":"/es/tags/respaldo-contenedores/","section":"Etiquetas","summary":"","title":"Respaldo-Contenedores","type":"tags"},{"content":"","date":"25 de abril de 2023","externalUrl":null,"permalink":"/es/tags/respaldo-kubernetes/","section":"Etiquetas","summary":"","title":"Respaldo-Kubernetes","type":"tags"},{"content":"","date":"25 de abril de 2023","externalUrl":null,"permalink":"/es/categories/vsphere-csi/","section":"Categorías","summary":"","title":"Vsphere-Csi","type":"categories"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/categories/aks/","section":"Categorías","summary":"","title":"Aks","type":"categories"},{"content":" Una de las arquitecturas que se utiliza en múltiples clientes con infraestructura híbrida es Google Anthos, una hermosa tecnologia que permite desplegar clusters de Kubernetes en distintos entornos utilizando la configuración de Google Kubernetes Engine, GKE, como tambien, agregar a Google Anthos otras distribuciones de Kubernetes de distintos proveedores o nubes públicas. En este post, revisaremos como es la arquitectura de Anthos y donde instalar Kasten K10 para proteger las aplicaciones.\nDocumentación Google Anthos # Como siempre revisaremos la documentación oficial de las plataformas o soluciones que estaremos revisando en este post, en este caso, Google Anthos, Google Kubernetes Engine y por supuesto Kasten K10 para proteger las aplicaciones.\nGoogle Anthos: https://cloud.google.com/anthos/docs/concepts/overview Kasten K10: https://docs.kasten.io/latest/index.html Por tanto, al leer la documentación podemos observar que Google Anthos nos permite administrar múltiples clusters de Kubernetes, ya sea, EKS, AKS, Bare Metal, VMware, entre otros. Además, de otras características que permiten realizar la validación de seguridad, aplicación de políticas de configuración para múltiples clusters, service mesh, entre otros.\nPara este post, revisaremos donde instalar Kasten K10 y como gestionar la protección de múltiples aplicaciones en clusters de kubernetes gesstionados por Google Anthos.\nRespaldo Google Cloud Anthos # Antes de instalar Kasten K10 para proteger nuestras aplicaciones en distintas distribuciones de kubernetes administradas por Google Anthos, debemos poner atención en la documentción sobre la protección de nodos que nos ofrece Google Anthos, particularmente en los siguientes links:\nhttps://cloud.google.com/anthos/clusters/docs/on-prem/latest/how-to/back-up-admin-cluster https://cloud.google.com/anthos/clusters/docs/on-prem/latest/how-to/back-up-user-cluster Como la documentación oficial lo indica, no existe protección para las aplicaciones, volúmenes persistentes, entre otros, que se ejecutan en los clusters de kubernetes administrados por Google Anthos. Por tanto, lo único que puede proteger desde Anthos, son las configuraciones de ETCD a través de snapshots para los clusters de administración y clusters de usuarios, inclusive en las nuevas características que estan en BETA y se menciona en la documentación para respaldar clusters de administración via gkectl, tiene limitantes adicionales, como por ejemplo, no es posible generar más de 6 respaldos de ETCD.\nEntonces, al observar estas limitantes y no centrarse en las aplicaciones que se ejecutan en los distintos clusters de Kubernetes manejados por Anthos, es que se hace necesario la utilización de Kasten K10, para proteger las aplicaciones ejecutándose en disntitas distribuciones de Kubernetes, permitiendo la protección, recuperación, migración y recuperación ante desastres de las aplicaciones en Kubernetes.\nArquitectura Kasten K10 con Google Anthos. # De hecho, una de las grandes virtudes de Kasten K10 es que puede proteger las aplicaciones de cualquier cluster Kubernetes soportado, ya sea desde el respaldo, recuperación, migración y recuperación ante desastres de las aplicaciones entre distintas distribuciones de Kubernetes. Permitiendo ofrecer una gestión centralizada de la protección y aportando esta gestión de datos a la arquitectura de Google Anthos.\nComo se puede observar en la imagen anterior, la arquitectura es muy sencilla con Kasten K10, ya que, solo hay que instalar K10 en cada uno de los clusters de Kubernetes gestionados por Google Anthos para luego designar o utilizar un cluster de administración para la gestión centralizada a través de Kasten K10 Multi-Cluster Manager.\nRecursos utilizados por Google Anthos en VMware # Para este post, se realizó la configuración de Google Anthos y el despliegue de clusters en VMware para validar las configuraciones y versiones de Kubernetes, en este caso, se desplegaron:\n1 VM: Admin Workstation (gloud cli y gestion de los recursos) 3 VM: 1 Control Plane y 2 Worker Node para el Cluster de Administracion 6 VM: 3 Control Plane y 3 Worker Nodes para el Cluster de Usuario (k10anthos) Recordemos que cuando se despliega un cluster de Kubernetes desde Google Anthos, la configuracion aplicada por ejemplo en VMware, es de acuerdo con las buenas practicas, es decir, utilizará el driver CSI de vSphere. Por supuesto siempre es posible configurar el cluster para la utilización de drivers que sean necesarios.\nRecursos desde Google Cloud Console # Esta configuración de Anthos puede ser realizada desde linea de comandos como tambien desde la consola grafica de Google Cloud, como se observa en la imagen anterior, Google Cloud, se autentica en los clusters de Kubernetes desplegados en el cluster de VMware para monitorear y aplicar las configuraciones de seguridad, políticas de administración, service mesh o lo que el administrador desee activar para la ejecución correcta de sus aplicaciones.\nDe hecho, es posible revisar todos los recursos utilizados y realizar cambios directamente desde la consola de Google Cloud, ya sea en la revisiones de las cargas de trabajo como tambien la edición de la cantidad de uso de CPU o RAM de los nodos administrados por Google Anthos.\nClusters de Kubernetes # Si revisamos los clusters creados usando kubectl, podemos ver la creación de los dos cluster, Admin y User, con sus respectivos nodos.\nComo se instala Kasten K10 en estos cluster?, es muy sencillo, se instala como si fuese un cluster de Kubernetes más, de hecho estos clusters estan basados en GKE, para la instalación, puede revisar los siguientes links de este blog:\n/veeam-kasten/#Instalacion_de_Kasten\n/instalar-kasten-multi-cluster-manager/\nKasten K10 Multi-Cluster Dashboard # Por supuesto, Google Anthos, al gestionar múltiples distribuciones de Kubernetes centralizadamente, necesita que la protección de las aplicaciones también sean gestionadas de forma centralizada, es por ello, que es necesario habilitar K10 Multi-Cluster Manager, para la gestión de los recursos, politicas y flujos de recuperación ante desastres entre distintas distribuciones de Kubernetes\nFinalizando, siempre es necesaria la utilización de Kasten K10 en todas las implementaciones de Kubernetes independientemente de la distribución de kubernetes, ya que en multiples casos se observan limitantes en relación a la protección de las apliaciones del negocio incluyendo la recuperación ante desastres.\nPosts relacionados # Como Instalar Kasten K10 en Google GKE Como Instalar Kasten K10 en AWS EKS Como Instalar Kasten K10 en Azure AKS Como Configurar Repositorio NFS para Kasten K10 Kasten K10 Multi-Cluster ","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/posts/como-usar-kasten-k10-con-google-anthos/","section":"Blog","summary":"Una de las arquitecturas que se utiliza en múltiples clientes con infraestructura híbrida es Google Anthos, una hermosa tecnologia que permite desplegar clusters de Kubernetes en distintos entornos utilizando la configuración de Google Kubernetes Engine, GKE, como tambien, agregar a Google Anthos otras distribuciones de Kubernetes de distintos proveedores o nubes públicas. En este post, revisaremos como es la arquitectura de Anthos y donde instalar Kasten K10 para proteger las aplicaciones.","title":"Como usar Kasten K10 con Google Anthos","type":"posts"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/categories/eks/","section":"Categorías","summary":"","title":"Eks","type":"categories"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/categories/gke/","section":"Categorías","summary":"","title":"Gke","type":"categories"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/tags/google-anthos/","section":"Etiquetas","summary":"","title":"Google-Anthos","type":"tags"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/tags/google-anthos-vmware/","section":"Etiquetas","summary":"","title":"Google-Anthos-Vmware","type":"tags"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/tags/kasten-anthos/","section":"Etiquetas","summary":"","title":"Kasten-Anthos","type":"tags"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/tags/kasten-multi-cluster/","section":"Etiquetas","summary":"","title":"Kasten-Multi-Cluster","type":"tags"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/categories/multi-tenant/","section":"Categorías","summary":"","title":"Multi-Tenant","type":"categories"},{"content":"","date":"18 de abril de 2023","externalUrl":null,"permalink":"/es/categories/tanzu/","section":"Categorías","summary":"","title":"Tanzu","type":"categories"},{"content":" Una de las opciones que muchas empresas utilizan para alojar sus respaldos es NFS, en esta guia, revisaremos como configurar un Perfil de NFS para ser utilizado por Kasten K10, de acuerdo con las buenas prácticas que se indican en la documentacion de Kasten.\nDocumentación # Antes que nada siempre debemos revisar la documentacion de las tecnologias que usaremos para conseguir nuestro objetivo, en este caso utilizaremos Kasten K10 y NFS Subdir External Provisioner, la información oficial la puedes encontrar:\nKasten K10 https://docs.kasten.io/latest/index.html NFS https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner Requerimientos # Para la utilización de NFS como perfil en Kasten K10, cómo lo indica la documentacion, necesitaremos cumplir con lo siguiente:\nServicio NFS accesible desde todos los nodos donde se encuentre instalado K10 Una carpeta compartida via NFS, que sea posible montar en todos los nodos donde se encuentre instalado K10 Un PV que defina la carpeta compartida NFS Un PVC con su respectivo StorageClassName para k10 Cumpliendo con los requerimientos anteriores tendremos configurado correctamente nuestro perfil NFS para alojar nuestros respaldos.\nConfiguracion Carpeta NFS # Como cualquier servidor NFS, es necesario crear una carpeta o utilizar una existente para alojar los respaldos, siempre con su respectiva configuración de acceso ya sea por autenticación o permitiendo los accesos por HOST en NFS, por ejemplo en mi QNAP he configurado lo siguiente:\nLuego de tener esto configurado, pasaremos a la instalación y configuración del NFS Subdir External Provisioner\nInstalación NFS Subdir External Provisioner # Nuevamente, de acuerdo a la documentacion de la solución, lo primero que debemos realizar, es la configuración del repositorio de helm, por tanto debemos ejecutar el siguiente comando:\nhelm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/ ```bash Para luego realizar la configuración con helm y su respectiva información del servidor NFS a utilizar: Validación de la instalación con: ```bash kubectl get pods ```bash ## Configuración StorageClass Para cumplir con los requerimientos de Kasten K10, debemos tener un StorageClass, de hecho, al realizar la instalación y configuración con helm, el StorageClass es creado automáticamente: ```bash kubectl get sc ```yaml ## Creación de Disco Persistente usando NFS Ahora, ya que tenemos todo, debemos probar la creación de PVC utilizando nuestro nuevo StorageClass, para ello ejecutaremos lo siguiente (modificar tamaño y nombre si es necesario): ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: prueba-disco-nfs spec: storageClassName: nfs-client accessModes: - ReadWriteMany resources: requests: storage: 100Gi ```bash Validar configuración en kubernetes y también en nuestra carpeta compartida NFS: Ahora eliminaremos este disco para preparar un disco necesario para Kasten K10: ```bash kubectl delete pvc prueba-disco-nfs ```bash Ahora crearemos el disco necesario para Kasten K10 en su propio namespace, con el siguiente archivo: ```bash kind: PersistentVolumeClaim apiVersion: v1 metadata: name: repo-nfs-respaldos namespace: kasten-io spec: storageClassName: nfs-client accessModes: - ReadWriteMany resources: requests: storage: 100Gi ```bash Si listamos los PVC sin namespace, veremos que no existe ninguno: ```bash kubectl get pvc ```bash Ahora, si listamos los PVC con el namespace kasten-io veremos nuestro nuevo disco: ```bash kubectl get pvc -n kasten-io Configuración perfil NFS Kasten K10 # Ahora, entraremos a la consola de Kasten K10 en el cluster que configuramos nuestro NFS, ingresando el nombre del PVC:\nValidamos la configuración:\nAhora probaremos un respaldo hacia este nuevo perfil de NFS para alojar los respaldos.\nPrueba Ejecución Respaldo hacia NFS # Para esto, solo debemos crear alguna política de respaldo usando nuestro nuevo perfil:\nLuego lo Ejecutamos y esperamos la finalización:\nValidamos el respaldo en nuestro NFS:\nY por último una prueba de recuperación en otro namespace en este caso, nfspacman:\nEn el dashboard de Kasten k10 veremos:\nY en kubernetes:\nY por último la aplicación pacman funcionando como se espera:\nPosts relacionados # Como Instalar Kasten K10 en AWS EKS Como Instalar Kasten K10 en Azure AKS Como Instalar Kasten K10 en Google GKE Como usar Kasten K10 con Google Anthos Actualizar Kasten k10 Configurar Alertas por Email en Kasten K10 ","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/posts/como-configurar-repositorio-nfs-para-kasten-k10/","section":"Blog","summary":"Una de las opciones que muchas empresas utilizan para alojar sus respaldos es NFS, en esta guia, revisaremos como configurar un Perfil de NFS para ser utilizado por Kasten K10, de acuerdo con las buenas prácticas que se indican en la documentacion de Kasten.","title":"Como Configurar Repositorio NFS para Kasten K10","type":"posts"},{"content":"","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/tags/como-configurar-nfs-kasten/","section":"Etiquetas","summary":"","title":"Como-Configurar-Nfs-Kasten","type":"tags"},{"content":"","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/categories/elastic-kubernetes-service/","section":"Categorías","summary":"","title":"Elastic-Kubernetes-Service","type":"categories"},{"content":"","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/tags/kasten/","section":"Etiquetas","summary":"","title":"Kasten","type":"tags"},{"content":"","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/tags/nfs/","section":"Etiquetas","summary":"","title":"NFS","type":"tags"},{"content":"","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/tags/nfs-profile-k10/","section":"Etiquetas","summary":"","title":"Nfs-Profile-K10","type":"tags"},{"content":"","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/tags/nfs-profile-kasten/","section":"Etiquetas","summary":"","title":"Nfs-Profile-Kasten","type":"tags"},{"content":"","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/tags/repositorio-nfs/","section":"Etiquetas","summary":"","title":"Repositorio-Nfs","type":"tags"},{"content":"","date":"23 de enero de 2023","externalUrl":null,"permalink":"/es/tags/respaldos/","section":"Etiquetas","summary":"","title":"Respaldos","type":"tags"},{"content":"","date":"17 de octubre de 2022","externalUrl":null,"permalink":"/es/categories/authentik/","section":"Categorías","summary":"","title":"Authentik","type":"categories"},{"content":"","date":"17 de octubre de 2022","externalUrl":null,"permalink":"/es/tags/authentik-kasten/","section":"Etiquetas","summary":"","title":"Authentik-Kasten","type":"tags"},{"content":"","date":"17 de octubre de 2022","externalUrl":null,"permalink":"/es/tags/k10-openid/","section":"Etiquetas","summary":"","title":"K10-Openid","type":"tags"},{"content":" Una de las características de Kasten K10 más utilizadas, es la integración con sistemas de autenticacion e identidad centralizados, a través de diferentes protocolos, para la gestión de acceso a los diferentes clusters de kubernetes utilizando RBAC por medio de K10 y/o para el acceso de K10 Multi-Cluster en ambientes con múltiples clusters de kubernetes. En este post, revisaremos la fácil configuración de Authentik e integración con Kasten K10.\nPasos Iniciales # En esta guía veremos lo fácil de la configuración de Authentik con Kasten K10, utilizando las variables por defecto de la instalación de Kasten K10 en relación a los grupos que utiliza para la la gestión de acceso basado por roles.\nComo es de costumbre, revisaremos la documentación oficial de los recursos que utilizaremos.\nAuthentik https://goauthentik.io/\nKasten K10 https://docs.kasten.io/latest/\nRBAC Kasten K10 https://docs.kasten.io/latest/access/rbac.html\nRBAC Kasten K10 Multi-Cluster Manage r https://docs.kasten.io/latest/multicluster/rbac.html\nAuthentik # Que es Authentik? Como ya hemos visto en este blog, existen múltiples soluciones Open Source para la gestión de identidad, roles, integración con kubernetes y/o acceso único de sesión (SSO), por ejemplo anteriormente hemos revisado Keycloak, en este post revisaremos Authentik, es cual es otra plataforma muy utilizada en distintas empresas para la gestión de acceso único, como también, la protección de acceso por autenticación de aplicaciones vía distintos protocolos o a través de proxy.\nKasten K10, soporta múltiples protocolos de autenticacion, por supuesto, utilizaremos OpenID el cual nos permite fácilmente autenticarnos entre Kasten y Kasten K10 para la gestión centralizada de usuarios. La instalación de Authentik es muy simple y posee distintas formas de instalación, en mi caso, lo instale sobre kubernetes con helm, puedes revisar las opciones en:\nhttps://goauthentik.io/docs/installation\nConfiguracion Requerimientos Authentik # Luego de la instalacion, Authentik solicita crear las credenciales del usuario inicial \u0026ldquo;akadmin\u0026rdquo;, para luego iniciar sesion en Authentik, ingresamos a la \u0026ldquo;Interfaz de Administrador\u0026rdquo;:\nAhora ingresaremos desde el menu en \u0026ldquo;Customisation\u0026rdquo;, \u0026ldquo;Property Mappings\u0026rdquo; y por ultimo clic en \u0026ldquo;Create\u0026rdquo;:\nEn esta etapa seleccionaremos \u0026ldquo;Scope Mapping\u0026rdquo; clic en \u0026ldquo;Next\u0026rdquo; y agregaremos el scope \u0026ldquo;groups\u0026rdquo; y la expresion como se aprecia en la siguiente imagen:\nreturn { \u0026#34;groups\u0026#34;: [group.name for group in request.user.ak_groups.all()], } ```bash Con la configuracion anterior, podremos utilizar o mapear los grupos de Kasten K10 para asignar accesos a la consola de K10, es decir, podremos crear usuarios en Authentik, crear y asignar los grupos de K10 a los usuarios creados y acceder, por tanto, validaremos que funcione correctamente haciendo clic en el icono de prueba, seleccionando un usuario y presionando \u0026#34;Test\u0026#34; Al traer los grupos a cuales pertenece el usuario significa que el \u0026#34;Scope\u0026#34; esta correctamente funcionando. Si el usuario no tiene ningun grupo asignado no mostrará nada, por tanto, ahora procederemos a crear el primer grupo de administracion para Kasten K10 en Authentik. ## Creación de Usuarios y Grupos en Authentik Para integrar Authentik con Kasten K10, necesitamos por supuesto crear usuarios y grupos que esta relacionados con K10, en este caso, comenzaremos creando el grupo \u0026#34;k10:admins\u0026#34;, el cual permite tener acceso como administrador a la consola de K10 o Multi-Cluster Manager, ingresaremos en \u0026#34;Directory\u0026#34; luego en \u0026#34;Groups\u0026#34; y haremos clic en \u0026#34;Create\u0026#34;: Ingresamos el nombre del grupo \u0026#34;k10:admins\u0026#34; y clic en \u0026#34;Create\u0026#34;: Ahora crearemos un usuario y en la misma creacion lo agregaremos al mismo grupo que recien creamos. Por tanto, ahora ingresaremos en \u0026#34;Directory\u0026#34; y luego \u0026#34;Users\u0026#34;, ingresamos el \u0026#34;Username\u0026#34;, \u0026#34;Name\u0026#34;, \u0026#34;Email\u0026#34;, y haciendo clic en \u0026#34;+\u0026#34; lo agregamos al grupo que creamos anteriormente. Lkuego, seleccionamos el usuario recien creado y hacemos clic en \u0026#34;Set Password\u0026#34; e ingresamos la contraseña deseada: ## Creación de OpenID en Authentik Ahora para que Authentik, pueda integrarse con Kasten K10, necesitamos habilitar y configurar el protocolo OpenID, ingresamos en \u0026#34;Applications\u0026#34;, luego en \u0026#34;Providers\u0026#34; y haremos clic en \u0026#34;Create\u0026#34; En esta etapa debemos seleccionar \u0026#34;OAuth2/OpenID Provider\u0026#34; y hacer clic en \u0026#34;Next\u0026#34; para pasar a la etapa más importante, ahora ingresamos el nombre y dejamops por defecto \u0026#34;Authorization Flow\u0026#34;: Ahora en \u0026#34;Protocol Settings\u0026#34; Donde: - **Client Type:** Confidential - **Client ID:** Se genera Automaticamente ( **copiar en un notepad**) - **Client Secret:** Se genera Automaticamente ( **copiar en un notepad**) - **Redirect Uri / Origins:** https://kasten.24xsiempre.com/k10/auth-svc/v0/oidc/redirect - **Signing Key:** Authentik Self-signed Luego en \u0026#34;Advanced protocol Settings\u0026#34;, asegurarse que el Scopes \u0026#34;groups\u0026#34; se encuentre seleccionado: Y por ultimo hacer clic en \u0026#34;Finish\u0026#34;. ## Creación de Aplicación en Authentik Para que Authentik provea el servicio, se genera una aplicación, ingresando en \u0026#34;Applications\u0026#34; y nuevamente en \u0026#34;Applications\u0026#34; para hacer clic en \u0026#34;Create\u0026#34;, ingresamos el \u0026#34;Name\u0026#34;, el \u0026#34;Slug\u0026#34; y en \u0026#34;Provider\u0026#34; seleccionamos el proveedor de OpenID que creamos anteriormente, finalizando con clic en \u0026#34;Create\u0026#34; ## Configuracion Kasten K10 Como vimos anteriormente en la documentacion, [https://docs.kasten.io/latest/access/rbac.html#k10-admin-binding](https://docs.kasten.io/latest/access/rbac.html#k10-admin-binding), sabemos que tenemos el gruopo \u0026#34;k10:admins\u0026#34; y ya lo tenemos mapeado con nuestra instalacion de Authentik, a continuacion veremos el comando a ejecutar en nuestra instalacion de Kasten K10 o en el cluster primario de K10 Multi-Cluster Manager: ```bash helm upgrade k10 kasten/k10 --namespace=kasten-io --set auth.oidcAuth.enabled=true --set auth.oidcAuth.providerURL=\u0026#34;https://atk.24xsiempre.com/application/o/kasten/\u0026#34; --set auth.oidcAuth.redirectURL=\u0026#34;https://kasten.24xsiempre.com/\u0026#34; --set auth.oidcAuth.scopes=\u0026#34;groups profile email\u0026#34; --set auth.oidcAuth.groupClaim=\u0026#34;groups\u0026#34; --set auth.oidcAuth.prompt=\u0026#34;login\u0026#34; --set auth.oidcAuth.clientID=\u0026#34;SuperDuperClientID\u0026#34; --set auth.oidcAuth.clientSecret=\u0026#34;SuperDuperClientSecret\u0026#34; --set auth.oidcAuth.usernameClaim=\u0026#34;email\u0026#34; --reuse-values --set externalGateway.create=true Ahora veremos que significa cada una de estas variables:\n–set auth.oidcAuth.enabled=true / Habilitamos autenticación OpenID –set auth.oidcAuth.providerURL=”https://atk.24xsiempre.com/application/o/kasten” / Url para Autenticarse –set auth.oidcAuth.redirectURL=”https://kasten.24xsiempre.com/” / Url de aplicacion K10 –set auth.oidcAuth.scopes=”groups profile email” / Client Scopes para validar –set auth.oidcAuth.groupClaim=”groups” / Nombre del grupo de Client Scope –set auth.oidcAuth.prompt=”login” / Mensaje de Login –set auth.oidcAuth.clientID=”SuperDuperClientID” / ID del Cliente –set auth.oidcAuth.clientSecret=”SuperDuperClientSecret” / Secret del cliente –set auth.oidcAuth.usernameClaim=”email” / En caso de autenticacion de email –reuse-values / Reusa valores ya configurados –set externalGateway.create=true / Reconfigura servicio gateway en K10 para acceder remoto Acceso Consola Kasten K10 # Al ingresar a la dirección url https://kasten.24xsiempre.com/k10/#/ y redireccionará al login de Authentik:\nIngresaremos usuario y contraseña\nCon esto finalizamos la configuración!\nPosts relacionados # Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1 Como Integrar Active Directory con Kasten K10 y OpenShift Kasten K10 Multi-Cluster Como Instalar Kasten K10 en AWS EKS Configurar Alertas por Email en Kasten K10 ","date":"17 de octubre de 2022","externalUrl":null,"permalink":"/es/posts/kasten-k10-authentik/","section":"Blog","summary":"Una de las características de Kasten K10 más utilizadas, es la integración con sistemas de autenticacion e identidad centralizados, a través de diferentes protocolos, para la gestión de acceso a los diferentes clusters de kubernetes utilizando RBAC por medio de K10 y/o para el acceso de K10 Multi-Cluster en ambientes con múltiples clusters de kubernetes. En este post, revisaremos la fácil configuración de Authentik e integración con Kasten K10.","title":"Kasten K10 Authentik","type":"posts"},{"content":"","date":"17 de octubre de 2022","externalUrl":null,"permalink":"/es/tags/kasten-sso/","section":"Etiquetas","summary":"","title":"Kasten-Sso","type":"tags"},{"content":"","date":"17 de octubre de 2022","externalUrl":null,"permalink":"/es/tags/sso/","section":"Etiquetas","summary":"","title":"Sso","type":"tags"},{"content":"","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/tags/alertas-email/","section":"Etiquetas","summary":"","title":"Alertas-Email","type":"tags"},{"content":"","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/tags/alertas-kasten/","section":"Etiquetas","summary":"","title":"Alertas-Kasten","type":"tags"},{"content":" En este guía revisaremos la instalación y configuración de prometheus con el objetivo de obtener alertas vía correo utilizando la federación, reglas y alertmanager de prometheus en conjunto con el monitoreo de Kasten K10.\nPasos Iniciales # Como es de costumbre, siempre, revisaremos la documentación oficial de las soluciones que instalaremos y/o configuraremos en esta guía.\nPrometheus: https://prometheus.io/\nKasten: https://docs.kasten.io/latest/operating/monitoring.html\nRealizaremos la configuración en una primera parte con la integración de K10 Multi-Cluster Manager y luego veremos como configurar las reglas cuando sea una instalación sin la administración centralizada.\nQue es Prometheus? # Prometheus es una solución enfocada en el monitoreo de los recursos de kubernetes basados en métricas en series temporales, es decir, monitoreo en tiempo real de las acciones que se tengan configuradas. Por ejemplo con prometheus podrías monitorear, vía reglas, el uso de CPU, Memoria, Conexiones, sesiones o lo que quieras configurar.\nAdemas es la solución estándar para el monitoreo de clústers de kubernetes ya que permite tener una vista muy detallada de los recursos a monitorear como también ayudarnos a la solución de los errores que existan.\nKasten K10 y Prometheus # Kasten también utiliza Prometheus para su monitoreo interno de K10. De hecho, en el link anterior, podemos ver que hay muchas métricas que Kasten k10 exporta a Prometheus como por ejemplo:\ncatalog jobs actions backup restore export import report run Entonces, como podemos realizar la configuración para que Prometheus nos envíe un email cuando por ejemplo, alguna política de respaldo no funcione correctamente?\nConfiguración Prometheus en Kasten K10 # Como sabemos, prometheus ya viene pre-instalado en Kasten K10, pero para esta instancia no se recomienda que sea modificada, ya que es administrado por helm y tiene ciertas configuraciones que funcionan directamente con los reportes por defecto de Kasten K10 y también para K10 Multi-Cluster Manager si lo tienes activado. Por tanto la idea es federar Prometheus que viene pre-instalado (para no modificarlo) con una instancia nueva de Prometheus:\nInstalación y Configuración Prometheus # Ahora procederemos a realizar la creación de un namespace para nuestra instancia de monitoreo, en este caso lo llamaremos alertas, para ello ejecutaremos lo siguiente en nuestro cluster de kubernetes:\nkubectl create ns alertas ```bash Y ahora agregaremos el repositorio para helm de Prometheus: ```bash helm repo add prometheus-community https://prometheus-community.github.io/helm-charts ```bash Y crearemos un nuevo archivo de nombre \u0026#34;kasten\\_prometheus\\_values\\_smtp.yaml\u0026#34;: ```bash defaultRules: create: false alertmanager: config: global: resolve_timeout: 5m route: repeat_interval: 30m receiver: \u0026#39;email\u0026#39; routes: - receiver: \u0026#39;email\u0026#39; match: severity: kasten receivers: - name: \u0026#39;email\u0026#39; email_configs: - to: SuperAdmin@email.com from: kastenalerts@24xsiempre.com smarthost: smtp.24xsiempre.com:25 auth_username: SuperDuperUserName auth_password: SuperDuperPassword prometheus: prometheusSpec: additionalScrapeConfigs: - job_name: k10 scrape_interval: 15s honor_labels: true scheme: http metrics_path: \u0026#39;/k10/prometheus/federate\u0026#39; params: \u0026#39;match[]\u0026#39;: - \u0026#39;{__name__=~\u0026#34;jobs.*\u0026#34;}\u0026#39; - \u0026#39;{__name__=~\u0026#34;catalog.*\u0026#34;}\u0026#39; static_configs: - targets: - \u0026#39;prometheus-server.kasten-io.svc.cluster.local\u0026#39; labels: app: \u0026#34;k10\u0026#34; #Valores para deshabilitar componentes que no son necesarios grafana: enabled: false kubeApiServer: enabled: false kubelet: enabled: false kubeStateMetrics: enabled: false kubeControllerManager: enabled: false kubeEtcd: enabled: false kubeProxy: enabled: false coreDns: enabled: false kubeScheduler: enabled: false ```bash Donde se debe editar las siguientes lineas: - **to**: SuperAdmin@email.com - **from**: kastenalerts@24xsiempre.com - **smarthost**: smtp.24xsiempre.com:25 - **auth\\_username**: SuperDuperUserName - **auth\\_password**: SuperDuperPassword Modificar las variables anteriores con los datos correctos y guardar \u0026#34;kasten\\_prometheus\\_values\\_smtp.yaml\u0026#34;: Y ahora realizamos la instalacion de Prometheus con el siguiente comando: ```bash helm install prometheus prometheus-community/kube-prometheus-stack -n alertas -f kasten_prometheus_values_smtp.yaml ```bash Y para validar que se haya instalado correctamente, ejecutamos: ```bash kubectl --namespace alertas get pods -l \u0026#34;release=prometheus\u0026#34; ```bash ## Creación de Reglas Prometheus para K10 Multi-Cluster Manager Aquí realizaremos la configuración más importante, ya que estamos usando K10 Multi-Cluster Manager, debemos saber identificar correctamente cada uno de los clusters que esta siendo protegidos por Kasten K10, por tanto, al leer la documentación aparece un \u0026#34;Tip\u0026#34; clave, donde indica que para identificar los clusters secundarios hay que agregar la variable {cluster=\u0026#34;desarrollo\u0026#34;} donde el nombre del cluster es como lo identificamos en Multi-Cluster Manager. Y para el cluster primario debe ser {cluster=\u0026#34;\u0026#34;}. Para esta guía, tengo configurado 3 clusters: - produccion (cluster primario para K10 Multi-Cluster) - desarrollo (cluster secundario para K10 Multi-Cluster) - tanzu (cluster secundario para K10 Multi-Cluster) Por tanto, crearemos el archivo de configuración con el nombre \u0026#34;alertas\\_cluster.yaml\u0026#34; y copiaremos el contenido: ```bash apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: labels: app: kube-prometheus-stack release: prometheus name: prometheus-kube-prometheus-kasten.rules spec: groups: - name: kasten_alert rules: - alert: K10JobsFailsClusterProd expr: |- increase(catalog_actions_count{cluster=\u0026#34;\u0026#34;, status=\u0026#34;failed\u0026#34;}[10m]) \u0026gt; 0 for: 1m labels: severity: kasten annotations: summary: \u0026#34;Politicas de Kasten K10 con error hace 10 minutos\u0026#34; description: \u0026#34;Politica \u0026lt;\u0026lt; {{ $labels.policy }} \u0026gt;\u0026gt; en cluster \u0026lt;\u0026lt; produccion \u0026gt;\u0026gt; Ha fallado en los ultimos 10 minutos\u0026#34; - alert: K10JobsFailsClusterDev expr: |- increase(catalog_actions_count{cluster=\u0026#34;desarrollo\u0026#34;, status=\u0026#34;failed\u0026#34;}[10m]) \u0026gt; 0 for: 1m labels: severity: kasten annotations: summary: \u0026#34;Politicas de Kasten K10 con error hace 10 minutos\u0026#34; description: \u0026#34;Politica \u0026lt;\u0026lt; {{ $labels.policy }} \u0026gt;\u0026gt; en cluster \u0026lt;\u0026lt; {{ $labels.cluster }} \u0026gt;\u0026gt; Ha fallado en los ultimos 10 minutos\u0026#34; - alert: K10JobsFailsClusterTanzu expr: |- increase(catalog_actions_count{cluster=\u0026#34;tanzu\u0026#34;, status=\u0026#34;failed\u0026#34;}[10m]) \u0026gt; 0 for: 1m labels: severity: kasten annotations: summary: \u0026#34;Politicas de Kasten K10 con error hace 10 minutos\u0026#34; description: \u0026#34;Politica \u0026lt;\u0026lt; {{ $labels.policy }} \u0026gt;\u0026gt; en cluster \u0026lt;\u0026lt; {{ $labels.cluster }} \u0026gt;\u0026gt; Ha fallado en los ultimos 10 minutos\u0026#34; ```bash Las variable a editar son en cada una de las alertas: - alert: Nombre de la Alerta - expr: SOLO editar el nombre del cluster (recuerda el tip anterior) - summary: Texto de resumen sin editar las variables - description: Texto descriptivo La variable mas importante en el archivo anterior es \u0026#34;expr\u0026#34; la cual es la \u0026#34;query\u0026#34; o consulta a prometheus de acuerdo con las metricas de Kasten K10 para detectar la falla en los jobs, si deseas crear nuevas consultas puedes visitar: [https://prometheus.io/docs/prometheus/latest/querying/basics/](https://prometheus.io/docs/prometheus/latest/querying/basics/) Y por ultimo crearemos las reglas en nuestra instancia de Prometheus: ```bash kubectl apply -f alertas_cluster.yaml -n alertas ```bash Y para validar la creación de la regla: ```bash kubectl get prometheusrules.monitoring.coreos.com -n alertas ```bash ## Creación de Reglas Prometheus sin K10 Multi-Cluster En caso de que tengas instalado Kasten K10 sin la utilización de K10 Multi-Cluster, también, es posible configurar reglas sin la necesidad de declarar el nombre del cluster, la única diferencia es la creación de la regla que debe ser como la siguiente: ```bash apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: labels: app: kube-prometheus-stack release: prometheus name: prometheus-kube-prometheus-kasten.rules spec: groups: - name: kasten_alert rules: - alert: K10JobsFail expr: |- increase(catalog_actions_count{status=\u0026#34;failed\u0026#34;}[10m]) \u0026gt; 0 for: 1m labels: severity: kasten annotations: summary: \u0026#34;Politicas de Kasten K10 con error hace 10 minutos\u0026#34; description: \u0026#34;Politica \u0026lt;\u0026lt; {{ $labels.policy }} Ha fallado en los ultimos 10 minutos\u0026#34; ```bash ## Prueba Alertas por Email Para probar esta configuración, necesitamos generar errores en las políticas de respaldo de los clusters, para eso, en los políticas de respaldos existentes eliminaremos los repositorios de respaldo de Kasten K10 o \u0026#34;Location Profiles\u0026#34; para forzar el error, donde las políticas se mostrarán así: Y por ultimo ejecutamos las políticas que generamos el error. Con esto deberíamos esperar que nos lleguen las alertas por email. Si ejecutamos el siguiente comando: ```bash kubectl port-forward service/prometheus-kube-prometheus-prometheus 9090:9090 -n alertas Podremos ingresar a la consola web de Prometheus para ver las reglas creadas:\nEl ejecutar las políticas de respaldo con errores, prometheus, detectara a través de las reglas que existen algunos errores:\nDonde por ultimo lo marca y se ejecuta el envío de la alertas por email:\nAlgunos ejemplos de las notificaciones o alertas que llegan al correo, donde incluye el nombre de la política de respaldo y su respectivo cluster donde existe el error:\nRecomendaciones # En algunos casos donde ya existan instancias de Prometheus, es posible, que al agregar la instancia para monitorear y federar prometheus de Kasten K10 no funcione correctamente, por ejemplo en Rancher, con \u0026ldquo;cattle-monitoring\u0026rdquo; es necesario deshabilitar el operator de prometheus, si no, ambas instancias trataran de sobreponerse con la otra obligando a los pods a reiniciarse.\nCon respecto a las notificaciones o alertas de Kasten K10, es posible crear nuevas querys o consultas para obtener otros tipos de datos, como por ejemplo, licencias, espacio utilizado, etc.\nPosts relacionados # Como Configurar Repositorio NFS para Kasten K10 Actualizar Kasten k10 Como Instalar Kasten K10 en AWS EKS Kasten K10 Multi-Cluster Kasten K10 Authentik ","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/posts/configurar-alertas-por-email-en-kasten-k10/","section":"Blog","summary":"En este guía revisaremos la instalación y configuración de prometheus con el objetivo de obtener alertas vía correo utilizando la federación, reglas y alertmanager de prometheus en conjunto con el monitoreo de Kasten K10.","title":"Configurar Alertas por Email en Kasten K10","type":"posts"},{"content":"","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/tags/kasten-k10/","section":"Etiquetas","summary":"","title":"Kasten-K10","type":"tags"},{"content":"","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/tags/kasten-prometheus/","section":"Etiquetas","summary":"","title":"Kasten-Prometheus","type":"tags"},{"content":"","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/tags/notificacion/","section":"Etiquetas","summary":"","title":"Notificacion","type":"tags"},{"content":"","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/categories/prometheus/","section":"Categorías","summary":"","title":"Prometheus","type":"categories"},{"content":"","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/tags/prometheus/","section":"Etiquetas","summary":"","title":"Prometheus","type":"tags"},{"content":"","date":"21 de julio de 2022","externalUrl":null,"permalink":"/es/categories/tanzu-kubernetes-grid/","section":"Categorías","summary":"","title":"Tanzu-Kubernetes-Grid","type":"categories"},{"content":" Una de las consultas recurrentes que tenemos últimamente es como configurar el Driver CSI de vSphere en entornos OpenShift 4.x sin la necesidad de utilizar el operador que ya desarrolló VMWare, pero que sólo esta soportado para producción a partir de la versión 4.10 de OpenShift. Por tanto, en esta guía revisaremos como instalar y configurar el driver en versiones anteriores a 4.10 sin la necesidad de usar el operador de VMware.\nIntroducción # Como es de conocimiento general, es posible realizar la instalación del Driver CSI de vSphere para aprovisionar volúmenes directamente como First Class Disk usando los DataStores configurados del ambiente vSphere. Además a partir de la versión 4.8 existe un operador de OpenShift en Preview para realizar la instalación del Driver CSI, el cual es soportado, para ambientes productivos completamente en la ultima versión de OpenShift 4.10.\nGeneralmente los usuarios de OpenShift no actualizan automáticamente a las últimas versiones de OpenShift hasta que sus aplicaciones y/o las nuevas características o versiones de kOpenShift tengan alguna actualización superior o se encuentren compatibles / soportadas, por tanto, esta guía es para realizar la instalación del driver CSI de vSphere desde la línea de comandos.\nEsta guía asume que el lector conoce del ambiente de OpenShift como también conectarse vía línea de comandos. En este caso se usa la version de OpenShift 4.8.39\nRequerimientos # Crearemos 2 archivos, csi-vsphere.conf y vsphere.conf, los cuales contienen las credenciales de acceso a vSphere:\ncsi-vsphere.conf\n[Global] # Para conseguir el ID del cluster se debe ejecutar el siguiente comando # oc get clusterversion -o jsonpath=\u0026#39;{.items[].spec.clusterID}{\u0026#34;\\n\u0026#34;}\u0026#39; cluster-id = \u0026#34;5341dc3e-4ea8-4de6-a4fd-f2715c75a0b8\u0026#34; [VirtualCenter \u0026#34;vcenter.24xsiempre.cl\u0026#34;] insecure-flag = \u0026#34;true\u0026#34; user = \u0026#34;SuperUserdevSphere\u0026#34; password = \u0026#34;SuperDuperPassword\u0026#34; port = \u0026#34;443\u0026#34; datacenters = \u0026#34;24xSiempre\u0026#34; ```bash En los puntos anteriores se debe ingresar la información de nuestro ambiente vSphere: - cluster-id: id del cluster de openshift, se debe ejecutar el comando que se indica en el archivo - VirtualCenter: dirección fqdn de vcenter - User: Usuario de vCenter que se usa con OpenShift - Password: Contraseña del usuario de vCenter - Datacenters: Nombre del Datacenter de vCenter Luego crearemos el siguiente archivo: vsphere.conf ```bash [Global] # Para conseguir el ID del cluster se debe ejecutar el siguiente comando # oc get clusterversion -o jsonpath=\u0026#39;{.items[].spec.clusterID}{\u0026#34;\\n\u0026#34;}\u0026#39; cluster-id = \u0026#34;5341dc3e-4ea8-4de6-a4fd-f2715c75a0b8\u0026#34; [VirtualCenter \u0026#34;vcenter.24xsiempre.cl\u0026#34;] insecure-flag = \u0026#34;true\u0026#34; user = \u0026#34;SuperUserdevSphere\u0026#34; password = \u0026#34;SuperDuperPassword\u0026#34; port = \u0026#34;443\u0026#34; datacenters = \u0026#34;24xSiempre\u0026#34; ```bash En los puntos anteriores se debe ingresar la información de nuestro ambiente vSphere: - cluster-id: id del cluster de openshift, se debe ejecutar el comando que se indica en el archivo - VirtualCenter: dirección fqdn de vcenter - User: Usuario de vCenter que se usa con OpenShift - Password: Contraseña del usuario de vCenter - Datacenters: Nombre del Datacenter de vCenter Luego de generar los archivos procederemos a configurar los “secrets” desde estos archivos, ejecutando los siguientes comandos: ```bash oc create secret generic vsphere-config-secret --from-file=csi-vsphere.conf --namespace=kube-system oc create configmap cloud-config --from-file=vsphere.conf --namespace=kube-system ```json Y para validar si fueron creados correctamente ejecutaremos: ```bash oc get secret vsphere-config-secret --namespace=kube-system oc get configmap cloud-config --namespace=kube-system ```bash Ahora procederemos a dejar todos los nodos en “Taint” con el siguiente comando: ```bash kubectl taint nodes --all \u0026#39;node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule\u0026#39; ```json Y procederemos a aplicar los siguientes archivos yaml: ```bash oc apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-roles.yaml oc apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml oc apply -f https://github.com/kubernetes/cloud-provider-vsphere/raw/master/manifests/controller-manager/vsphere-cloud-controller-manager-ds.yaml ```json Y para validar la correcta aplicación de los archivos anteriores, ejecutaremos: ```bash oc describe nodes | grep \u0026#34;ProviderID\u0026#34; ```json ## Instalación vSphere-CSI Ahora aplicaremos la instalación del driver con la aplicación de los siguientes archivos: ```bash oc apply -f https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/v2.1.1/manifests/v2.1.1/vsphere-7.0u1/vanilla/rbac/vsphere-csi-controller-rbac.yaml oc apply -f https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/v2.1.1/manifests/v2.1.1/vsphere-7.0u1/vanilla/deploy/vsphere-csi-node-ds.yaml oc apply -f https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/v2.1.1/manifests/v2.1.1/vsphere-7.0u1/vanilla/deploy/vsphere-csi-controller-deployment.yaml ```json Ejecutaremos el siguiente comando: ```bash oc get deployments --namespace=kube-system ```text Y esperaremos hasta que “READY” se encuentre en el estado 1/1: Y Validaremos la instalación del driver en los nodos con el siguiente comando: ```bash oc get CSINode ```bash ## Creación de StorageClass Ahora pasaremos a la configuración del StorageClass para que utilice el driver CSI de vSphere. Antes de todo en vCenter generaremos un “Storage Policy”, este caso de nombre “Contenedores” el cual debe estar asociado al DataStore que utilizaremos para alojar nuestros discos persistentes: Luego editamos el siguiente archivo: ```bash cat \u0026lt;\u0026lt; EOF | kubectl apply -f - kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: sc-csi-vsphere annotations: storageclass.kubernetes.io/is-default-class: \u0026#34;false\u0026#34; provisioner: csi.vsphere.vmware.com parameters: StoragePolicyName: \u0026#34;Contenedores\u0026#34; datastoreURL: \u0026#34;ds:///vmfs/volumes/60634600-6fcc5d36-bd83-dcfe07e145f9/\u0026#34; EOF Donde debemos modificar los siguientes parámetros:\nname: Es el nombre que deseamos para el StorageClass. StoragePolicyName: El nombre del “Storeage Policy” que creamos anteriormente. datastoreURL: La URL del Datastore de vCenter. En la siguiente imagen esta la info. Luego de los cambios que aplicamos en el archivo, lo ejecutaremos en la consola y nos mostrará:\nY también lo podremos validar en la consola de OpenShift:\nCreación de Disco Persistente # Crearemos un disco persistente desde la consola de OpenShift para validar la creación y eliminación de discos con el nuevo StorageClass. Ingresaremos en la consola de OpenShift, Storage, PersistenVolumeClaims y haremos clic en “Create PersistentVolumeClaim”:\nSeleccionamos el StorageClass que creamos con vSphere CSI Ingresamos el Nombre del Volumen Ingresamos el tamaño Clic en “Create” Y veremos la creación del disco en OpenShift:\nEn el Datastore configurado:\nAhora eliminaremos el disco para validar el correcto funcionamiento:\nConfirmación en OpenShift:\nConfirmación de Eliminación en vCenter:\nConfiguración StorageClass por defecto # Ingresaremos en la consola de OpenShift, luego, Storage y haremos clic en “StorageClasses”, donde veremos:\nComo se puede observar en la imagen anterior el StorageClass por defecto es “thin”, el cual es creado automáticamente al instalar OpenShift, seleccionaremos el “thin”, luego “Edit Annotations” y cambiaremos el parámetro “storageclass.kubernetes.io/is-default-class” a “false” y guardamos:\nY por último, seleccionamos nuestro StorageClass que usa el driver CSI de vSphere, en este caso, “sc-csi-vsphere”, clic en “Edit Annotations” y cambiamos el parámetro “storageclass.kubernetes.io/is-default-class” a “true” y guardamos:\nAhora veremos que nuestro StorageClass es por defecto y cada nueva creación de discos persistentes lo usará:\nPor tanto, ahora solo falta instalar Kasten K10 para proteger todas tus aplicaciones en OpenShift, donde en este blog existen múltiples guías para instalar y configurar Kasten K10.\nPosts relacionados # Red Hat OpenShift en vSphere con Kasten Instalar Cluster de Kubernetes con vSphere CSI Como Integrar Active Directory con Kasten K10 y OpenShift Veeam + Kasten ","date":"31 de mayo de 2022","externalUrl":null,"permalink":"/es/posts/como-instalar-vsphere-csi-driver-en-redhat-openshift-4-x/","section":"Blog","summary":"Una de las consultas recurrentes que tenemos últimamente es como configurar el Driver CSI de vSphere en entornos OpenShift 4.x sin la necesidad de utilizar el operador que ya desarrolló VMWare, pero que sólo esta soportado para producción a partir de la versión 4.10 de OpenShift. Por tanto, en esta guía revisaremos como instalar y configurar el driver en versiones anteriores a 4.10 sin la necesidad de usar el operador de VMware.","title":"Como Instalar vSphere CSI Driver en RedHat OpenShift 4.x","type":"posts"},{"content":"","date":"31 de mayo de 2022","externalUrl":null,"permalink":"/es/tags/openshift-csi-driver/","section":"Etiquetas","summary":"","title":"Openshift-Csi-Driver","type":"tags"},{"content":"","date":"31 de mayo de 2022","externalUrl":null,"permalink":"/es/tags/storageclass-openshift-csi/","section":"Etiquetas","summary":"","title":"Storageclass-Openshift-Csi","type":"tags"},{"content":"","date":"31 de mayo de 2022","externalUrl":null,"permalink":"/es/tags/vcenter-openshift/","section":"Etiquetas","summary":"","title":"Vcenter-Openshift","type":"tags"},{"content":"","date":"31 de mayo de 2022","externalUrl":null,"permalink":"/es/tags/vmware-openshift/","section":"Etiquetas","summary":"","title":"Vmware-Openshift","type":"tags"},{"content":"","date":"31 de mayo de 2022","externalUrl":null,"permalink":"/es/tags/vsphere-csi/","section":"Etiquetas","summary":"","title":"Vsphere-Csi","type":"tags"},{"content":"","date":"18 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/aks/","section":"Etiquetas","summary":"","title":"AKS","type":"tags"},{"content":"","date":"18 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/azure-aks/","section":"Etiquetas","summary":"","title":"Azure-Aks","type":"tags"},{"content":" Continuando con la serie de guías para la protección de aplicaciones sobre servicios de Kubernetes en nubes públicas, ahora es el turno de Microsoft Azure Kubernetes Service o Azure AKS, donde revisaremos paso a paso la instalación, configuración y ejecución de políticas de respaldos con Kasten K10, integrando la consola con K10 Multi-Cluster Manager para conseguir una gestión y protección centralizada de las aplicaciones en AKS.\nPrimeros Pasos # Siempre debemos revisar la documentación oficial de Kasten, para la instalación debemos revisar los siguientes enlaces y por supuesto nunca olvidar la ejecución de los \u0026ldquo;Pre-Flight Checks\u0026rdquo;:\nhttps://docs.kasten.io/latest/install/requirements.html https://docs.kasten.io/latest/install/azure/azure.html Ahora pasaremos a conectarnos vía \u0026ldquo;cli\u0026rdquo; a nuestro cluster AKS desde la interfaz de consola en el portal de Azure o desde tu computador donde administras tus clusters de kubernetes. En el caso de que aún no tengas configurado el archivo kubeconfig, solo debes ejecutar el siguiente comando en la shell de Azure:\naz aks get-credentials -g 24xsiempre -n demoaks ```bash Donde después de \u0026#34;-g\u0026#34; debes ingresar el nombre del \u0026#34;Resource Group\u0026#34; asociado y después del \u0026#34;-n\u0026#34; debes ingresar el nombre del cluster AKS, con el comando anterior se creará el archivo \u0026#34;config\u0026#34; dentro de la carpeta \u0026#34;.kube\u0026#34; en el home del usuario. Y para validar, puedes listar los nodos del cluster AKS ejecutando: ```bash kubectl get nodes -o wide ```bash ## Instalar Kasten K10 en Azure AKS Ya que estamos conectados al cluster Azure AKS, ejecutaremos el comando de pre-requisitos que nos indica la documentación de Kasten, por tanto procederemos a crear el namespace \u0026#34;kasten-io\u0026#34; para luego ejecutar el script: ```bash helm repo add kasten https://charts.kasten.io/ kubectl create namespace kasten-io curl https://docs.kasten.io/tools/k10_primer.sh | bash ```bash Es muy importante registrar los mensajes que entrega el script de pre-check, ya que nos indicará que hace falta un \u0026#34;VolumeSnapshotClass\u0026#34; para el StorageClass que se esta utilizando por defecto en AKS, que revisaremos más adelante. Antes de proceder con la instalación vía \u0026#34;helm\u0026#34;, debemos registrar una aplicación en Azure para obtener las variables necesarias, por tanto en el portal de Azure, el el directorio por defecto, crearemos una nueva aplicación: Luego crearemos la clave en \u0026#34;Certificados y Secretos\u0026#34;, asignaremos el nombre y creamos: Luego de la creación de la aplicación en Azure, tomaremos los siguientes datos: - azureTenantId - azureClientId - azureClientSecret Los primeros dos ID los encontrarás en la \u0026#34;Informacion General\u0026#34; de la aplicacion creada y el tercero o secret lo copias desde la creacion anterior, para generar el siguiente comando: ```bash helm install k10 kasten/k10 --namespace=kasten-io \\ --set secrets.azureTenantId=9afedb96-a2f5-4e9c-a78a-123456789012 \\ --set secrets.azureClientId=849b0886-5fa1-4464-863d-123456789012 \\ --set secrets.azureClientSecret=REPLACE_WITH_YOUR_AZURE_CLIENT_SECRET \\ --set externalGateway.create=true \\ --set auth.tokenAuth.enabled=true ```bash Con lo anterior, instalamos Kasten K10 en Azure AKS incluyendo la creación del \u0026#34;LoadBalancer\u0026#34; y la autenticacion por token, que hemos revisado en muchas ocasiones. Para validar el correcto funcionamiento de Kasten K10, debes ejecutar el comando: ```bash kubectl get pods -n kasten-io ```bash Al estar todos los pods en \u0026#34;Running\u0026#34; procederemos a revisar cual es la dirección IP de acceso a la interfaz web de Kasten K10 con el siguiente comando: ```bash kubectl get svc -n kasten-io ```bash Por tanto, el acceso a la consola, en este caso, es http://20.98.177.166/k10/ donde podremos autenticarnos vía token: Si aun no sabes como extraer el token ```bash sa_secret=$(kubectl get serviceaccount k10-k10 -o jsonpath=\u0026#34;{.secrets[0].name}\u0026#34; --namespace kasten-io) kubectl get secret $sa_secret --namespace kasten-io -ojsonpath=\u0026#34;{.data.token}{\u0026#39;\\n\u0026#39;}\u0026#34; | base64 --decode ```bash ## Integración con K10 Multi-Cluster Manager Si aún no tienes instalado K10 Multi-Cluster Manager, revisa: /instalar-kasten-multi-cluster-manager/ Y en este caso para Microsoft AKS debemos copiar el kubeconfig del cluster AKS, dentro de la shell de Azure ejecutaremos: ```text cat .kube/config ```bash Copiamos el kubeconfig y lo pegamos en nuestro K10 Multi-Cluster Manager, despues de hacer clic en \u0026#34;Add Cluster\u0026#34;: Un dato importante, en este caso, no es necesario preparar el archivo kubeconfig con el ejecutable k10multicluster, como si lo necesitan otros proveedores, por tanto, la configuración es directa, ingresas el nombre del cluster que aparecerás, la dirección del \u0026#34;Ingress URL\u0026#34; y por ultimo deshabilitando la verificación TLS. En caso de tener activado TLS, solo déjalo por defecto y podrás ver el cluster AKS en la consola Multi-Cluster: ## Azure Blob Storage Ahora configuraremos en \u0026#34;Location Profiles\u0026#34; un repositorio para alojar nuestros respaldos, ingresamos el nombre, seleccionamos \u0026#34;Azure Storage\u0026#34; e ingresamos las credenciales, ubicación y contenedor Al guardar el \u0026#34;Profile\u0026#34; tendremos nuestro repositorio para alojar respaldos y se verá: ## Política de Respaldo Azure AKS Crearemos una política de respaldo básica seleccionando \u0026#34;Snapshot\u0026#34; y utilizando el repositorio creado anteriormente para luego ejecutar la politica: Cuando la política se ejecuta y trata de realizar un snapshot al volumen persistente que esta utilizando , en este caso, MongoDB, nos mostrará el siguiente error: ```text ... Failed to run CSI prechecks for PVC Failed to get K10 VolumeSnapshotClass ... ```bash Y aqui es donde se demuestra que es muy importante ejecutar el script que revisa los \u0026#34;Pre-Flight Checks\u0026#34;, ya que al ejecutarlo por primera vez nos indicará que no existe el \u0026#34;VolumeSnapshotClass\u0026#34; como lo vimos anteriormente. Por tanto, procederemos a crear el VSC con el siguiente comando: ```bash cat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: annotations: k10.kasten.io/is-snapshot-class: \u0026#34;true\u0026#34; name: csi-azure-vsc driver: disk.csi.azure.com deletionPolicy: Delete parameters: incremental: \u0026#34;true\u0026#34; EOF ```bash Y luego ejecutamos nuevamente el script de \u0026#34;Pre-Flight Checks\u0026#34;: ```bash curl https://docs.kasten.io/tools/k10_primer.sh | bash Y veremos el mensaje exitoso de la configuración correcta de este VSC con el StorageClass por defecto. Luego ejecuta nuevamente la política de respaldo y terminará exitosamente:\nRespaldos en Azure Blob # Para el respaldo, podremos ver los archivos generados por Kasten K10 en el contenedor de Azure Blob que configuramos anteriormente en \u0026ldquo;Location Profiles\u0026rdquo;, ingresando al explorador de Storage del portal de Microsoft Azure:\nRecomendaciones # Como siempre, la seguridad es lo primero, aplicando accesos solo por direcciones de confianza como también aplicar RBAC al acceso vía Multi-Cluster Manager y por supuesto si es necesario aplicar los permisos a las cuentas de servicios con el mínimo de acceso para el funcionamiento.\nPosts relacionados # Como Instalar Kasten K10 en AWS EKS Como Instalar Kasten K10 en Google GKE Como usar Kasten K10 con Google Anthos Como Configurar Repositorio NFS para Kasten K10 Configurar Alertas por Email en Kasten K10 Veeam + Kasten ","date":"18 de marzo de 2022","externalUrl":null,"permalink":"/es/posts/como-instalar-kasten-k10-en-azure-aks/","section":"Blog","summary":"Continuando con la serie de guías para la protección de aplicaciones sobre servicios de Kubernetes en nubes públicas, ahora es el turno de Microsoft Azure Kubernetes Service o Azure AKS, donde revisaremos paso a paso la instalación, configuración y ejecución de políticas de respaldos con Kasten K10, integrando la consola con K10 Multi-Cluster Manager para conseguir una gestión y protección centralizada de las aplicaciones en AKS.","title":"Como Instalar Kasten K10 en Azure AKS","type":"posts"},{"content":"","date":"18 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/microsoft-azure-kubernetes-service/","section":"Etiquetas","summary":"","title":"Microsoft-Azure-Kubernetes-Service","type":"tags"},{"content":" De acuerdo a las ultimas encuestas por cncf.io y otras empresas, uno de los servicios más utilizados es Google Kubernetes Engine, GKE, por tanto, como es de esperar, siempre se necesita realizar la protección de las aplicaciones que se ejecutan en este tipo de servicios, como también, la utilización de la infraestructura de Google para almacenar los respaldos. En esta guía veremos como instalar Kasten K10 para proteger las aplicaciones que se ejecutan en GKE y ademas integrarlo con K10 Multi-Cluster Manager.\nPrimeros Pasos # Como siempre debemos visitar la documentación oficial de Kasten K10 para instalar la solución en Google Kubernetes Engine:\nRequerimientos: https://docs.kasten.io/latest/install/requirements.html#install-prereqs\nInstalación en Google GKE: https://docs.kasten.io/latest/install/google/google.html\nDespués de leer la documentación confirmaremos lo sencillo que es instalar Kasten K10 en Google Kubernetes Engine, ya que, la recomendación es instalarlo con una cuenta de servicios (Service Account), ya que Kasten necesita dos tipos de cuentas de servicio, una para acceder a la infraestructura de Google, como por ejemplo el almacenamiento y otra para acceder a los recursos de kubernetes. Revisaremos la opción de una cuenta de servicio por separada ya que es la recomendación y buena practica para realizar la protección de las aplicaciones en GKE\nCreación Cuenta de Servicio Google Cloud # Primero nos aseguraremos que estamos en la consola de Google Cloud y tenemos acceso al Cluster de GKE:\nLuego accederemos a la \u0026ldquo;Cloud Shell\u0026rdquo; de Google haciendo clic en el icono de \u0026ldquo;Prompt\u0026rdquo; al lado izquierdo del signo de interrogación en el lado superior derecho de la consola de Google:\nLuego ejecutaremos el siguiente comando para acceder al cluster GKE:\ngcloud container clusters get-credentials NombreMiClusterGKE --zone ZonaGoogle ```bash Donde debes ingresar el nombre de tu cluster GKE y la zona donde la configuraste, por ejemplo en este caso, el nombre del cluster es \u0026#34;demo-gke-k10\u0026#34; y la zona es \u0026#34;us-central1-c\u0026#34;: Con esto, aseguramos la configuración del archivo kubeconfig en .kube/config para la gestión via kubectl, si ejecutamos el siguiente comando veremos los nodos en ejecución en GKE: ```bash kubectl get nodes -o wide ```bash Ya estamos en condiciones de generar la cuenta de servicio. Importante, los permisos que necesitaremos agregar a la cuenta de servicio serán: - roles/compute.storageAdmin para el acceso a la infraestructura de Google - roles/storage.admin para el acceso a los bucket para respaldo en Google Cloud Storage \\\\*\\\\*\\\\* De acuerdo con la seguridad de cada empresa puedes segmentar los permisos de storage.admin \\*\\*\\* Por tanto, como se indica en la documentación de Kasten procederemos a ejecutar los siguientes comandos en la Cloud Shell de Google: ```bash myproject=$(gcloud config get-value core/project) gcloud iam service-accounts create k10-sa --display-name \u0026#34;K10 Service Account\u0026#34; k10saemail=$(gcloud iam service-accounts list --filter \u0026#34;k10-sa\u0026#34; --format=\u0026#34;value(email)\u0026#34;) gcloud iam service-accounts keys create --iam-account=${k10saemail} k10-sa-key.json gcloud projects add-iam-policy-binding ${myproject} --member serviceAccount:${k10saemail} --role roles/compute.storageAdmin ```bash Luego agregaremos los permisos para el acceso a los buckets, por que podría ser la misma cuenta de servicio u otra que se utilice exclusivamente para acceder a los buckets de Google Cloud Storage. Para validar podremos ir a \u0026#34;IAM\u0026#34; dentro de la consola de Google Cloud y confirmaremos al creación de la cuenta de servicio: Como se ve en la imagen anterior observamos que existe \u0026#34;k10-sa@inspiring-cat-342913.iam.gserviceaccount.com\u0026#34; que es la cuenta de servicio que se ha creado anteriormente con los comandos ejecutados y luego editaremos la cuenta, en este caso, para usarlo para que también acceda a Google Cloud Storage, agregaremos el rol Storage.Admin a la cuenta de servicio: Y podremos validar que se ha asignado el rol necesario: ## Instalación de Kasten K10 Si seguimos al pie de la letra la documentación de Kasten K10, para la instalación, siempre debemos revisar los requisitos previos que mencioné al inicio de este post, agregaremos el repositorio de helm y crearemos el namespace para kasten, de nombre \u0026#34;kasten-io\u0026#34; con los siguiente comandos: ```bash helm repo add kasten https://charts.kasten.io/ kubectl create namespace kasten-io ```bash Ya con lo anterior creado, procedemos a instalar Kasten K10 con la cuenta de servicio que creamos anteriormente y su respectiva key con los siguientes comandos: ```bash sa_key=$(base64 -w0 k10-sa-key.json) helm install k10 kasten/k10 --namespace=kasten-io --set secrets.googleApiKey=$sa_key ```bash Por ultimo revisamos que todos los pods del namespace estén en \u0026#34;RUNNING\u0026#34;: ```bash kubectl get pods -n kasten-io ```bash Ahora necesitamos acceder a la consola web de Kasten y como lo hemos configurado varias veces en este blog, solo debemos ejecutar el comando: ```bash helm upgrade k10 kasten/k10 --namespace=kasten-io \\ --reuse-values \\ --set externalGateway.create=true \\ --set auth.tokenAuth.enabled=true ```bash Nuevamente validamos que los pods del namespace de kasten este en \u0026#34;RUNNING\u0026#34; y luego revisamos el servicio que se ha creado para acceder a la consola con el siguiente comando: ```bash kubectl get svc -n kasten-io ```bash Y vemos que en este caso tengo asignada la ip: 34.121.31.71 como \u0026#34;LoadBalancer\u0026#34;, ingresaremos a la web con http://34.121.31.71/k10/#/ Y la credencial es obtener del token, como vimos en un post anterior en este blog, solo debemos ejecutar: ```bash sa_secret=$(kubectl get serviceaccount k10-k10 -o jsonpath=\u0026#34;{.secrets[0].name}\u0026#34; --namespace kasten-io) kubectl get secret $sa_secret --namespace kasten-io -ojsonpath=\u0026#34;{.data.token}{\u0026#39;\\n\u0026#39;}\u0026#34; | base64 --decode ```bash Y nos mostrará el token para ingresar: ## Configuración Infraestructura Google Ya mencionamos que Kasten necesita acceso a la infraestructura de Google como también a Google Cloud Storage para alojar los respaldos, ya que configuramos con la cuenta de servicio, el perfil de infraestructura se genera en Kasten automáticamente, para validar, lo podemos ver en la configuración del cluster de Kasten \u0026#34;Settings\u0026#34; y luego en \u0026#34;Infraestructure\u0026#34;: Ya solo nos falta agregar el repositorio de respaldos con un bucket de Google Cloud Storage, crearemos el bucket de Google de la forma estándar y luego desde kasten ingresas los siguientes datos: Para generar el service key, ingresamos a \u0026#34;IAM\u0026#34;, luego \u0026#34;Service Accounts\u0026#34;, seleccionamos la cuenta de servicio de Kasten que creamos \u0026#34;k10-sa\u0026#34;, clic en \u0026#34;Keys\u0026#34; y generamos una en formato json: Donde: - Profile Name: Nombre del perfil - Cloud Storage Provider: Seleccionamos Google Cloud Storage - GCP Project ID: Tomamos el nombre del ID del Projecto de Google en este caso \u0026#34;inspiring-cat-342913\u0026#34; - GCP Service key: Copiamos el contenido del json que generamos anteriormente - Location: Ubicacion del bucket cuando se genero o lo puedes ver en las propiedades del bucket - Bucket Name: Nombre del bucket creado con anterioridad Y ya estamos listos para realizar respaldos. ## Integración con K10 Multi-Cluster Manager En el siguiente post veremos como integrar nuestro cluster GKE con K10 Multi-Cluster manager, si necesitas instalar K10 Multi-Cluster: /instalar-kasten-multi-cluster-manager/ Y en este caso para Google, debemos ejecutar k10multicluster para modificar el kubeconfig del cluster. Para copiar el kubeconfig del cluster GKE, debemos ejecutar en la \u0026#34;Cloud Shell\u0026#34;: ```text cat .kube/config ```bash Entramos a nuestro cluster primario de kubernetes para Kasten, e ingresamos a la ruta: ```text cd cd .kube/ ```text Y generaremos una archivo con nano de nombre google para pegar el contenido del kubeconfig: ```text nano google ```bash Lo configuramos como variable de entorno en tu perfil y puedes listar los contextos de kubernetes: ```bash kubectl config get-contexts ```json Y nos centramos en el contexto de Google, en este caso gke\\_inspiring-cat-342913\\_us-central1-c\\_demo-gke-k10 y ejecutaremos el siguiente comando (recuerda poner el contexto de tu cluster): ```text k10multicluster kubeconfig prepare --context gke_inspiring-cat-342913_us-central1-c_demo-gke-k10 Copiamos el contenido de archivo creado en nuestro K10 Multi-Cluster,\nCluster Display Name: nombre que deseamos mostrar del cluster Ingress URL: Direccion de la consola de Kasten en GKE K10 Namespace: Nombre del namespace donde se instalo Kasten Helm release name: k10 Insecure TLS: En caso de usar http deshabilitarlo, de lo contrario usar SSL con un certificado valido. Y ya tenemos nuestro cluster Google GKE gestionado centralizadamente.\nRecomendaciones # Como siempre, la seguridad es lo primero, aplicando accesos solo por direcciones de confianza como también aplicar RBAC al acceso vía Multi-Cluster Manager y por supuesto si es necesario aplicar los permisos a las cuentas de servicios con el mínimo de acceso para el funcionamiento.\nPosts relacionados # Como Instalar Kasten K10 en AWS EKS Como Instalar Kasten K10 en Azure AKS Como usar Kasten K10 con Google Anthos Como Configurar Repositorio NFS para Kasten K10 Kasten K10 Multi-Cluster Veeam + Kasten ","date":"2 de marzo de 2022","externalUrl":null,"permalink":"/es/posts/como-instalar-kasten-k10-en-google-gke/","section":"Blog","summary":"De acuerdo a las ultimas encuestas por cncf.io y otras empresas, uno de los servicios más utilizados es Google Kubernetes Engine, GKE, por tanto, como es de esperar, siempre se necesita realizar la protección de las aplicaciones que se ejecutan en este tipo de servicios, como también, la utilización de la infraestructura de Google para almacenar los respaldos. En esta guía veremos como instalar Kasten K10 para proteger las aplicaciones que se ejecutan en GKE y ademas integrarlo con K10 Multi-Cluster Manager.","title":"Como Instalar Kasten K10 en Google GKE","type":"posts"},{"content":"","date":"2 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/gke/","section":"Etiquetas","summary":"","title":"GKE","type":"tags"},{"content":"","date":"2 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/google-cloud/","section":"Etiquetas","summary":"","title":"Google-Cloud","type":"tags"},{"content":"","date":"2 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/google-cloud-storage/","section":"Etiquetas","summary":"","title":"Google-Cloud-Storage","type":"tags"},{"content":"","date":"2 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/google-gke/","section":"Etiquetas","summary":"","title":"Google-Gke","type":"tags"},{"content":"","date":"2 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/google-kubernetes/","section":"Etiquetas","summary":"","title":"Google-Kubernetes","type":"tags"},{"content":"","date":"2 de marzo de 2022","externalUrl":null,"permalink":"/es/tags/google-kubernetes-engine/","section":"Etiquetas","summary":"","title":"Google-Kubernetes-Engine","type":"tags"},{"content":"","date":"10 de febrero de 2022","externalUrl":null,"permalink":"/es/tags/aws-eks/","section":"Etiquetas","summary":"","title":"Aws-Eks","type":"tags"},{"content":"","date":"10 de febrero de 2022","externalUrl":null,"permalink":"/es/tags/backup-eks/","section":"Etiquetas","summary":"","title":"Backup-Eks","type":"tags"},{"content":" Uno de los servicios más utilizados nativos de la nube, son los contenedores orquestados por Kubernetes, donde los servicios de nube publica son uno de los más usados para este tipo de carga de trabajo. De hecho en una de las encuestas de cncf.io del 2020, nos muestra que alrededor del 60% de los usuarios / empresas utilizan almacenamiento nativo de nube para sus contenedores directamente desde Google (81%), AWS (80%) y Azure (74%), seguro que estos porcentajes han cambiado en estos años. Es por esto que en este post revisaremos como proteger todos los contenedores en AWS EKS.\nPasos Iniciales # Inicialmente, ya que mencioné el reporte de cncf.io, lo puedes revisar aquí:\nhttps://www.cncf.io/wp-content/uploads/2020/12/CNCF_Survey_Report_2020.pdf\nComo siempre debemos revisar la documentación oficial de Kasten:\nhttps://docs.kasten.io/latest/install/aws/aws.html\nAquí veremos la forma recomendada de instalación, existiendo otra, pero debemos tratar siempre se acercarnos a las buenas practicas.\nInstalación Kasten con IAM Role # La forma recomendada es utilizar la integración con un rol de IAM asociado a una cuenta de servicio, en este caso, k10-k10, por tanto comenzaremos creando las políticas de IAM para asignar los permisos de acuerdo a la configuración oficial de Kasten:\nhttps://docs.kasten.io/latest/install/aws/using_aws_iam_roles.html#using-aws-iam-roles https://docs.kasten.io/latest/install/aws/aws_permissions.html El primer link nos indica los permisos necesarios para realizar snapshots, restaurar y migrar entre distintos cluster. En el segundo link nos aparecen todos los permisos por cada servicio que se necesita acceso de acuerdo a lo que necesites proteger. En este caso veremos 3 políticas de IAM para crear y tener una granularidad de permisos a la cuenta de servicio.\nGeneraremos 3 políticas, asociadas al json que nos muestra la documentación de Kasten, por ejemplo, para hacer la política de AWS EBS debemos hacer clic en \u0026ldquo;Crear Política\u0026rdquo;, clic en \u0026ldquo;JSON\u0026rdquo; y pegamos el contenido:\nLuego, clic en siguiente, para aplicar tags y luego como último paso ingresaremos el nombre de la política:\n**Importante: Se debe realizar la creación de las políticas necesarias, por tanto, se debe repetir este paso, con las políticas para los servicios necesarios del segundo link anterior**\nHabilitar OIDC en EKS # Debemos utilizar Cloudshell o una configuración local de aws cli, configurando la autenticacion como un usuario administrador para la gestión de los siguientes comandos.\nPara contar con una autenticación correcta, podemos configurar OIDC en nuestro cluster EKS con el siguiente comando (debes ingresar el nombre de tu cluster):\neksctl utils associate-iam-oidc-provider --cluster NombreCluster --approve ```bash Como se indica en la documentacion: [https://docs.kasten.io/latest/install/aws/using\\_aws\\_iam\\_roles.html#creating-an-iam-role-for-k10-install](https://docs.kasten.io/latest/install/aws/using_aws_iam_roles.html#creating-an-iam-role-for-k10-install) Se debe considerar que el nombre del la cuenta de servicio que crearemos debe ser \u0026#34;k10-k10\u0026#34;, el namespace \u0026#34;kasten-io\u0026#34; y ademas agregar el ARN de las políticas que generamos, para obtener los ARN de las políticas, debes ingresar en IAM y hacer clic en el nombre de la política para ver el ARN, copiamos cada uno de los ARN de las políticas creadas anteriormente: Ahora crearemos el namespace \u0026#34;kasten-io\u0026#34; ```bash kubectl create ns kasten-io ```bash Y luego generamos la cuenta de servicio con el siguiente comando: ```bash eksctl create iamserviceaccount \\ --name k10-k10 \\ --namespace kasten-io \\ --cluster Lab-EKS \\ --attach-policy-arn arn:aws:iam::123456789000:policy/k10-EBS \\ --attach-policy-arn arn:aws:iam::123456789000:policy/k10-RDS \\ --attach-policy-arn arn:aws:iam::123456789000:policy/k10-S3 \\ --approve \\ --override-existing-serviceaccounts ```bash **\\*\\*recuerda ingresar el nombre del cluster EKS y el ARN de cada politica\\*\\*** Luego de esto veremos en IAM, un nuevo Rol: Como se observa en la imagen anterior, las políticas están asociadas a este nuevo rol generado y asociado a la cuenta de servicio. Copiaremos el ARN del nuevo rol y pasaremos a la instalación de Kasten K10 ## Instalación Kasten K10 AWS EKS Como ya hemos visto varias veces en este blog, debemos tener configurado \u0026#34;helm\u0026#34; con su respectivo chart, lo puedes ver aquí: /veeam-kasten/#Instalacion\\_de\\_Kasten Y ahora instalaremos Kasten K10 con el siguiente comando: ```bash helm install k10 kasten/k10 --namespace=kasten-io --set secrets.awsIamRole=\u0026#34;arn:aws:iam::123456789000:role/eksctl-Lab-EKS-addon-iamserviceaccount-kaste-Role1-12FASDASDCKA\u0026#34; ```bash **\\*Recuerda que debes ingresar el ARN del Rol creado anteriormente\\*** \\\\*\\\\* En caso de que aparezca un error reclamando sobre la existencia de un cuenta de servicio, solo elimina y crea nuevamante el namsespace kasten-io\\*\\* Esperamos que los pods de \u0026#34;kasten-io\u0026#34; queden en estado \u0026#34;running\u0026#34; revisándolos con el siguiente comando: ```bash watch kubectl get pods -n kasten-io ```bash Si deseas ver los discos que se crearon automáticamente con la instalación de Kasten K10: ```bash kubectl get pvc -n kasten-io ```bash Por último necesitamos acceso a la consola de Kasten K10, sólo debemos ejecutar el siguiente comando: ```bash helm upgrade k10 kasten/k10 --namespace=kasten-io \\ --reuse-values \\ --set externalGateway.create=true \\ --set auth.tokenAuth.enabled=true ```bash Lo cual creara un servicio de \u0026#34;Load Balancer\u0026#34; y asignara una dirección dns de AWS: ```bash kubectl get svc gateway-ext -n kasten-io ```bash Solo debemos ingresar a la url, en este caso: http://a8c57c2bded63432194a6545af3ce024-1753718719.sa-east-1.elb.amazonaws.com/k10/#/ y procederemos a autenticarnos como se observa en la documentación oficial: [https://docs.kasten.io/latest/access/authentication.html#obtaining-tokens](https://docs.kasten.io/latest/access/authentication.html#obtaining-tokens) Hasta aquí ya puedes usar Kasten K10 para realizar respaldo de tus cargas en AWS EKS :) ## Integrar con K10 Multi-Cluster Manager AWS EKS Ya hemos visto anteriormente como instalar K10 Multi-Cluster Manager, si no lo haz revisado aún: /kasten-rbac-multi-tenant-multi-cluster-keycloak/ O instalar K10 Multi-Cluster Manager sin Keycloak: /instalar-kasten-multi-cluster-manager/ Ahora, nos queda configurar el archivo kubeconfig en nuestra interfaz de Multi-Cluster Manager, intentaremos agregar el cluster por la interfaz web, haciendo clic en \u0026#34;Add Clusters\u0026#34; y pegaremos el contenido del archivo kubeconfig de nuestro cluster AWS EKS y nos mostrará lo siguiente: Como vemos, no se puede seleccionar el cluster, ya que K10MultiCluster necesita un paso anterior para preparar el archivo kubeconfig correctamente, para ello realizaremos el siguiente comando para identificar el contexto de kubernetes usado: ```bash kubectl config get-contexts ```json Copiamos el nombre del contexto y luego ejecutamos el comando: ```text k10multicluster kubeconfig prepare --context arn:aws:eks:sa-east-1:12345678900:cluster/Lab-EKS Copiamos el contenido después de \u0026ldquo;\u0026mdash;\u0026rdquo; y lo pegamos nuevamente en K10 Multi-Cluster Manager en \u0026ldquo;Add Clusters\u0026rdquo; y veremos que ahora están habilitadas las opciones para agregar el cluster de AWS EKS:\nSeleccionamos el cluster y lo pasamos hacia la derecha, para luego ingresar el \u0026ldquo;Cluster Display Name\u0026rdquo;, la \u0026ldquo;Ingress URL\u0026rdquo; que es la direccion url que se nos asigno en los servicios de kasten-io, siempre agregando como lo indica la interfaz, namespace \u0026ldquo;kasten-io\u0026rdquo;, release name de helm \u0026ldquo;k10\u0026rdquo; y deshabilitar el TLS, ya que lo estamos agregando sin TLS, en caso de que configures el acceso con certificado, habilitas, luego clic en \u0026ldquo;Add Clusters\u0026rdquo;:\nY tendremos el cluster de AWS EKS en nuestra K10 Multi-Cluster Manager configurado para aplicar las políticas necesarias.\nAgregar bucket S3 con el Rol IAM # Como anteriormente configuramos todos los permisos asociados a una cuenta de servicio de kasten k10 y las políticas asociadas al rol creado, cuando configuramos un \u0026ldquo;Location Profile\u0026rdquo; podremos usar el mismo IAM Role para la autenticacion seleccionando:\nIngresamos la Región, Nombre del bucket y guardamos el profile, por supuesto si el bucket tiene habilitada la inmutabilidad también la puedes usar.\nRecomendaciones # Siempre las recomendaciones son a nivel de seguridad, siempre solo permite las direcciones IP\u0026rsquo;s autorizadas para que accedan a los servicios de kasten, a través de reglas de firewall para conservar la privacidad, por otra parte, si es necesario generar mas permisos al rol, solo debes generar la política necesaria, como por ejemplo para respaldar con los permisos necesarios de RDS y asociarlo al rol generado.\nPosts relacionados # Como Instalar Kasten K10 en Azure AKS Como Instalar Kasten K10 en Google GKE Como usar Kasten K10 con Google Anthos Como Configurar Repositorio NFS para Kasten K10 Kasten K10 Multi-Cluster Veeam + Kasten ","date":"10 de febrero de 2022","externalUrl":null,"permalink":"/es/posts/como-instalar-kasten-k10-en-aws-eks/","section":"Blog","summary":"Uno de los servicios más utilizados nativos de la nube, son los contenedores orquestados por Kubernetes, donde los servicios de nube publica son uno de los más usados para este tipo de carga de trabajo. De hecho en una de las encuestas de cncf.io del 2020, nos muestra que alrededor del 60% de los usuarios / empresas utilizan almacenamiento nativo de nube para sus contenedores directamente desde Google (81%), AWS (80%) y Azure (74%), seguro que estos porcentajes han cambiado en estos años. Es por esto que en este post revisaremos como proteger todos los contenedores en AWS EKS.","title":"Como Instalar Kasten K10 en AWS EKS","type":"posts"},{"content":"","date":"10 febrero 2022","externalUrl":null,"permalink":"/en/tags/eks-backup/","section":"Tags","summary":"","title":"Eks-Backup","type":"tags"},{"content":"","date":"10 de febrero de 2022","externalUrl":null,"permalink":"/es/tags/iam-role/","section":"Etiquetas","summary":"","title":"Iam-Role","type":"tags"},{"content":"","date":"10 de febrero de 2022","externalUrl":null,"permalink":"/es/tags/kasten-eks/","section":"Etiquetas","summary":"","title":"Kasten-Eks","type":"tags"},{"content":"","date":"10 de febrero de 2022","externalUrl":null,"permalink":"/es/tags/kasten-k10-eks/","section":"Etiquetas","summary":"","title":"Kasten-K10-Eks","type":"tags"},{"content":"","date":"10 de febrero de 2022","externalUrl":null,"permalink":"/es/tags/respaldo-eks/","section":"Etiquetas","summary":"","title":"Respaldo-Eks","type":"tags"},{"content":" Y seguimos con este excelente tema que estamos revisando, en el post anterior revisamos todo lo relacionado a la configuración de clusterroles, roles, bindings para Kasten K10, creando cluster roles para Administradores y para Operadores de un cluster en particular. En este ultimo post veremos la configuración de roles, clusterroles, bindings con Kasten K10 Multi-Cluster Manager y por supuesto con Keycloak para la gestion de Usuarios y Grupos.\nConfiguración Kasten K10 Multi-Cluster Keycloak # \\\\\\* La idea de esta serie es explicar como generar los grupos, roles, clusterroles y demás recursos asociados a RBAC, sin la necesidad de estar modificando directamente en el cluster de kubernetes los permisos de usuario durante el tiempo, así toda la gestión de creación de usuario, grupos, asignación de grupos se realiza en Keycloak. ***\n***La configuración de OpenID con Kasten K10 Multi-Cluster Manager es casi idéntica a la de Kasten K10, ya que se necesitan los mismos pasos para habilitar la autenticación, los repetiré en este post, en caso de que hayas llegado directo aquí.***\nDebemos conectarnos al cluster primario de Kubernetes donde se encuentra instalado Kasten K10 Multi-Cluster Manager y procederemos a la configuración de autenticación con Keycloak, pero antes, necesitamos extraer el \u0026ldquo;Secret\u0026rdquo; desde nuestro \u0026ldquo;Client\u0026rdquo; kasten en el menú \u0026ldquo;Credentials\u0026rdquo; reemplazando en la variable \u0026ldquo;auth.oidcAuth.clientSecret\u0026rdquo;, (reemplazar SuperDuperClientSecret) y por supuesto reemplazando los valores por tus datos de DNS o IP, ejecutando el siguiente comando (por seguridad elimine parte del secret):\nhelm upgrade k10 kasten/k10 --namespace=kasten-io --set auth.oidcAuth.enabled=true --set auth.oidcAuth.providerURL=\u0026#34;https://auth.24xsiempre.com/auth/realms/kasten\u0026#34; --set auth.oidcAuth.redirectURL=\u0026#34;https://kasten.24xsiempre.com/\u0026#34; --set auth.oidcAuth.scopes=\u0026#34;groups profile email\u0026#34; --set auth.oidcAuth.groupClaim=\u0026#34;groups\u0026#34; --set auth.oidcAuth.prompt=\u0026#34;login\u0026#34; --set auth.oidcAuth.clientID=\u0026#34;kasten\u0026#34; --set auth.oidcAuth.clientSecret=\u0026#34;SuperDuperClientSecret\u0026#34; --set auth.oidcAuth.usernameClaim=\u0026#34;email\u0026#34; --reuse-values --set externalGateway.create=true ```bash Ahora veremos que significa cada uno de estas variables: - **--set auth.oidcAuth.enabled=true** / Habilitamos autenticación OpenID - **--set auth.oidcAuth.providerURL=\u0026#34;https://auth.24xsiempre.com/auth/realms/kasten\u0026#34;** / Url para Autenticarse - **--set auth.oidcAuth.redirectURL=\u0026#34;https://kasten.24xsiempre.com/\u0026#34;** / Url de aplicacion K10 - **--set auth.oidcAuth.scopes=\u0026#34;groups profile email\u0026#34;** / Client Scopes para validar - **--set auth.oidcAuth.groupClaim=\u0026#34;groups\u0026#34;** / Nombre del grupo de Client Scope - **--set auth.oidcAuth.prompt=\u0026#34;login\u0026#34;** / Mensaje de Login - **--set auth.oidcAuth.clientID=\u0026#34;kasten\u0026#34;** / Nombre del Cliente en el Realm creado. - **--set auth.oidcAuth.clientSecret=\u0026#34;SuperDuperClientSecret\u0026#34;** / Secret del cliente - **--set auth.oidcAuth.usernameClaim=\u0026#34;email\u0026#34;** / En caso de autenticacion de email - **--reuse-values** / Reusa valores ya configurados - **--set externalGateway.create=true** / Reconfigura servicio gateway en K10 para acceder remoto Un dato importante si ya tienes configurado un método de autenticación para Kasten, es mejor desactivarlo y luego ejecutar el comando anterior en caso de error. ## Acceso Usuarios Como ya tenemos todo configurado, la creación del usuario que realizamos en el post anterior, solo nos queda ingresar a la interfaz web de keycloak y asegurarnos que tenga estos permisos el usuario: - Usuario: kastenadmin - Password: SuperDuperPassword o la que se haya aplicado - Grupo: k10:admins Luego solo ingresaremos a la Url de Kasten en mi caso https://kasten.24xsiempre.com/k10/#/ y nos redirigirá a el formulario de ingreso de Keycloak en el realm de Kasten, ingresamos las credenciales: Y podremos observar que tenemos un ingreso exitoso y con todos los permisos ya que pertenecemos al grupo \u0026#34;k10:admins\u0026#34; y no tuvimos que editar ningún ClusterRole o Roles. Para confirmar los permisos, es posible validarlos gráficamente ya sea viendo \u0026#34;permissions\u0026#34; \u0026#34;unrestricted\u0026#34; o entrando al cluster primario, luego \u0026#34;Cluster Settings\u0026#34; , después \u0026#34;Support\u0026#34; y por ultimo clic en \u0026#34;View Current User Details\u0026#34; y podrás visualizar todos los permisos de ese usuario y al grupo que pertenece: ## Creación de Roles de Acceso en Kasten K10 Multi-Cluster Manager Como vimos anteriormente, tenemos configurado el cluster primario de Kasten K10. Ahora configuraremos los roles necesarios asociados a grupos para acceder a Kasten K10 Multi-Cluster Manager ### Usuario Administrador Importante señalar que K10 Multi-Cluster Manager esta pensado solo para administradores, es posible dar acceso a un usuario regular sin permisos de administración sobre Multi-Cluster Manager, aun así, como vimos en el post anterior, es posible dar acceso completo a un usuario al cluster protegido por K10 inclusive si esta usando recursos o distribuciones de Multi-Cluster Manager Al usar Multi-Cluster Manager es posible administrar los usuarios con Keycloak. Como mencione anteriormente para la administración es necesario pertenecer al grupo \u0026#34;k10:admins\u0026#34; Y si validamos acceso: Ahora, necesito acceso a K10 Multi-Cluster Manager como usuario sin la posibilidad de modificar configuraciones globales. ### Usuario Operador Por lo general siempre es necesario un usuario con permisos limitados a nivel de K10 Multi-Cluster Manager, recordando siempre, que es posible asignar un rol de operación directo a un grupo de usuarios para Kasten K10 sin la necesidad de acceder al Multi-Cluster Manager, por tanto, en Keycloak cambiaremos el grupo del usuario \u0026#34;kastenadmin\u0026#34; a \u0026#34;k10:mc-user\u0026#34; Si validamos acceso obtendremos el siguiente error: El error anterior es por que no se a generado el RoleBinding para el grupo \u0026#34;k10:mc-user\u0026#34;, por tanto lo realizaremos de la siguiente forma: ```bash kubectl create rolebinding k10-mc-user-demo --clusterrole=k10-mc-user \\ --namespace=kasten-io-mc \\ --group=k10:mc-user ```bash Validaremos la creacion del RoleBinding: ```bash kubectl get rolebindings -n kasten-io-mc Y validamos acceso a Kasten:\nComo vemos en la imagen anterior, no tiene acceso al cluster \u0026ldquo;qadesarrollo\u0026rdquo; y tampoco puede visualizar los recursos del cluster primario. Es una buena practica en caso de otorgar acceso al K10 Multi-Cluster Manager, restringir la administración del cluster primario, ya que en este cluster se concentra la configuración centralizada de todos los recursos.\nAsignación K10ClusterRoles en Multi-Cluster Manager # Como ya realizamos el binding del grupo a nivel de clusterrole, necesitamos permitir acceso al usuario a la administración de un cluster de preferencia, por tanto, con un usuario administrador, que pertenezca al grupo \u0026ldquo;k10:admins\u0026rdquo;, agregaremos al usuario \u0026ldquo;kastenadmin\u0026rdquo; a un K10ClusterRole para que pueda administrar un cluster.\nAl generar el K10ClusterRole, indicamos que es administrador del cluster \u0026ldquo;qadesarrollo\u0026rdquo;, recuerda que existen 3 K10ClusterRoles que puedes asignar al usuario \u0026ldquo;k10-multi-cluster-admin\u0026rdquo;, \u0026ldquo;k10-multi-cluster-basic\u0026rdquo;, \u0026ldquo;k10-multi-cluster-config-view\u0026rdquo; y si validamos acceso nuevamente observaremos que ya tiene los permisos necesarios:\nConclusiones y Recomendaciones # Como vimos en esta serie de 3 posts, es posible utilizar todo el RBAC para acceder con permisos granulares a los recursos de Kasten K10 y Kasten K10 Multi-Cluster Manager, inclusive siendo administrados los cluster centralizadamente, es posible generar acceso directo al cluster deseado por algún cliente o usuario de Kasten sin la necesidad de acceso al Multi-Cluster, es por ellos que siempre se recomienda utilizar una solución de SSO, como en este caso Keycloak o la de tu preferencia ya que el protocolo OpenID es estandard. Como recomendación, siempre utilizar el principio de menor privilegio posible e ir otorgando permisos de acuerdo a la necesidad de la operación, como también, generar los ClusterRoles específicos para luego solo agregar grupos de usuarios.\nDemo Kasten K10 # Si por cualquier motivo, necesitas probar este tipo de acceso, he dejado la plataforma operativa en el laboratorio, para que cualquier usuario se registre y pueda acceder al K10 Multi-Cluster Manager y poder jugar con el ambiente de pruebas, para hacer el registro y conseguir acceso solo debes ingresar en:\nhttps://kasten.24xsiempre.com\nY Hacer clic en \u0026ldquo;Registrate\u0026rdquo; / \u0026ldquo;Register\u0026rdquo;\nAl registrarte, pedirá verificación del correo y luego ya tendrás acceso al laboratorio. :)\nPosts relacionados # Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1 Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 2 Kasten K10 Authentik Como Integrar Active Directory con Kasten K10 y OpenShift ","date":"27 de enero de 2022","externalUrl":null,"permalink":"/es/posts/kasten-rbac-multi-tenant-multi-cluster-keycloak-3/","section":"Blog","summary":"Y seguimos con este excelente tema que estamos revisando, en el post anterior revisamos todo lo relacionado a la configuración de clusterroles, roles, bindings para Kasten K10, creando cluster roles para Administradores y para Operadores de un cluster en particular. En este ultimo post veremos la configuración de roles, clusterroles, bindings con Kasten K10 Multi-Cluster Manager y por supuesto con Keycloak para la gestion de Usuarios y Grupos.","title":"Kasten RBAC Multi-Tenant Multi-Cluster Keycloak – 3","type":"posts"},{"content":"","date":"27 de enero de 2022","externalUrl":null,"permalink":"/es/tags/kasten-keycloak/","section":"Etiquetas","summary":"","title":"Kasten-Keycloak","type":"tags"},{"content":"","date":"27 de enero de 2022","externalUrl":null,"permalink":"/es/categories/keycloak/","section":"Categorías","summary":"","title":"Keycloak","type":"categories"},{"content":"","date":"27 de enero de 2022","externalUrl":null,"permalink":"/es/tags/keycloak/","section":"Etiquetas","summary":"","title":"Keycloak","type":"tags"},{"content":"","date":"27 de enero de 2022","externalUrl":null,"permalink":"/es/tags/multi-tenant/","section":"Etiquetas","summary":"","title":"Multi-Tenant","type":"tags"},{"content":"","date":"27 de enero de 2022","externalUrl":null,"permalink":"/es/tags/role-based-access-control/","section":"Etiquetas","summary":"","title":"Role-Based-Access-Control","type":"tags"},{"content":"","date":"27 de enero de 2022","externalUrl":null,"permalink":"/es/tags/service-provider/","section":"Etiquetas","summary":"","title":"Service-Provider","type":"tags"},{"content":" En este post, veremos la configuración de Role Based Access Control (RBAC) en conjunto con Kasten K10 para el acceso a uno o múltiples clusters protegidos por Kasten, esta dirigido tanto a clientes que manejen 1 o más clusters de cualquier distribución de kubernetes soportado por K10, como también a proveedores de servicios (SP o MSP) que ofrezcan el respaldo de contenedores de kubernetes con Kasten K10, con el objetivo de brindar un acceso controlado a los usuarios / clientes de acuerdo a los roles granulares necesarios por cada cluster u operación. Ademas utilizaremos una solución de Single Sign-On (SSO) usando OpenID en este caso, Keycloak, para la gestión centralizada de las credenciales de acceso ya sea para usuarios o grupos.\nPasos Iniciales # La idea de esta serie es explicar como generar los grupos, roles, clusterroles y demás recursos asociados a RBAC, sin la necesidad de estar modificando directamente en el cluster de kubernetes durante el tiempo, así toda la gestión de creación de usuario, grupos, asignación de grupos se realiza en Keycloak.\nComo es de costumbre en este blog, siempre debemos recurrir a la documentación oficial de lo que vamos a instalar / configurar o aplicar, ya que debemos mantenernos lo más cercano a las buenas practicas o directrices de los creadores de las soluciones que utilizaremos.\nKeycloak https://www.keycloak.org/documentation\nKasten K10 https://docs.kasten.io/latest/\nRBAC Kasten K10 https://docs.kasten.io/latest/access/rbac.html\nRBAC Kasten K10 Multi-Cluster Manager https://docs.kasten.io/latest/multicluster/rbac.html\nInstalación de K10 y Multi-Cluster # No entraremos en profundidad en la instalación de los productos en este post, ya que en los siguiente links tienes paso a paso la instalación de Kasten K10 y Kasten Multi-Cluster Manager:\nKasten K10 /veeam-kasten/\nKasten K10 Multi-Cluster Manager /instalar-kasten-multi-cluster-manager/\nY con respecto a la instalación de Keycloak, es muy sencillo desde helm o puedes usar una de las tantas guías en internet para instalarlo como contenedor o como una aplicativo en un servidor. (Deja un comentario si necesitas una guía paso a paso)\nAhora pasaremos a revisar un resumen de los roles y clusterroles existentes para la creacion de los permisos granulares.\nKasten K10 RBAC # Cuando revisamos la documentación, observamos que existe RBAC para la instalación individual de kasten k10, manteniendo los estándares de kubernetes así como también tenemos RBAC para instalaciones en múltiples cluster usando Multi-Cluster Manager.\nEn este caso revisaremos la aplicación de Roles, RoleBinding, ClusterRole, ClusterRoleBindings sobre kasten k10 para conseguir una acceso granular a nuestra implementación de k10 de acuerdo a la necesidad de la operación. Por tanto, al revisar la documentación nos encontraremos con los ClusterRoles por defecto que se crean al instalar K10, los cuales son 3:\nk10-admin / Acceso total a la implementación de Kasten K10 k10-basic / Acceso operacional a usuarios en recursos específicos k10-config-view / Acceso a la configuración sin permisos para crear o modificar Los puedes listar con el siguiente comando:\nkubectl get clusterrole | grep k10 ```bash De hecho si se revisa en detalle los permisos consultando cada clusterrole como por ejemplo: ```bash kubectl describe clusterrole k10-admin ```bash Se observan todos los permisos, recursos y verbs (lo que puede hacer) de cada uno de los clusterroles, los cuales son la base para la creación de permisos granulares de acceso a K10. Es posible utilizarlos como base para luego crear clusterrolebinding asociado a usuarios o grupos de usuarios que accederán vía OpenID. Uno de los roles importantes que también existen dentro de la instalación de K10 es el rol **k10-ns-admin** el cual provee acceso a los secrets y también para ver el estado de los servicios directamente desde la consola de K10, para listar el rol, se debe incluir el namespace **kasten-io** ```bash kubectl get roles -n kasten-io ```bash ## K10 Multi-Cluster Manager RBAC Al igual que lo anterior cuando se configura K10 Multi-Cluster Manager desde el cluster primario, se generan 2 clusterroles por defecto y ademas clusterroles específicos de k10: - k10-mc-admin / Permite acceso total a la administración de múltiples clusters y recursos - k10-mc-user / Permite acceso al cluster pero no a los recursos de administración ```bash kubectl get clusterrole | grep k10-mc ```bash Clusterroles específicos de K10 para la gestión de RBAC dentro de K10 Multi-Cluster - k10-multi-cluster-admin / Permite acceso total a la administración de múltiples clusters y recursos - k10-multi-cluster-basic / Permite acceso al cluster pero no a los recursos de administración - k10-multi-cluster-config-view / Permite acceso al cluster y a la visualización de configuración ```bash kubectl get k10clusterrole -n kasten-io-mc Por que tienen dos tipos de clusterroles? los primeros roles son asociados a los recursos y clusters de kubernetes y los k10clusterroles son asociado a la gestión interna del Multi-Cluster Manager con el objetivo de brindar acceso vía RBAC dentro de K10.\nEn esta guia configuraremos clusterroles y roles específicos de acuerdo a la necesidad de acceso y operación utilizando los recursos que nos provee Kasten K10, pero antes pasaremos a la configuracion de Keycloak\nConfiguración Keycloak # Después de la instalación de Keycloak, es posible acceder al dominio o realm \u0026ldquo;master\u0026rdquo; vía web con el usuario que hayan configurado, por ejemplo, en mi caso utilizo auth.24xsiempre.com e ingreso a la consola de administración:\nPuedes mantener las configuraciones por defecto o habilitar al menos la detecion de fuerza bruta en el menú de \u0026ldquo;Security Defenses\u0026rdquo;.\nAhora, crearemos un nuevo Realm exclusivo para Kasten K10, por tanto seleccionaremos el en menu principal el realm \u0026ldquo;master\u0026rdquo; y haremos clic en \u0026ldquo;Add Realm\u0026rdquo;, luego ingresamos el nombre del nuevo realm y por ultimo clic en \u0026ldquo;create\u0026rdquo;:\nDentro de \u0026ldquo;Realm Settings\u0026rdquo; existen varias configuraciones como se observan en el menú de Keycloak, para este caso habilitaremos en \u0026ldquo;Security Defenses\u0026rdquo; la detección de fuerza bruta (opcional, pero recomendado) y lo mas importante en el menú \u0026ldquo;Login\u0026rdquo; las siguientes opciones:\nDe preferencia utilizar estas opciones, para el caso de \u0026ldquo;forgot password\u0026rdquo; y \u0026ldquo;Verify Email\u0026rdquo; es necesario tener configurado SMTP en Keycloak donde es muy fácil ingresar dirección, usuario y contraseña del servidor SMTP en el menú \u0026ldquo;Email\u0026rdquo; .\nConfiguración Cliente Keycloak # Ya tenemos lo básico de Keycloak, ahora entraremos de lleno a la configuración de un cliente en Keycloak para la utilización de OpenID en conjunto con K10. Clic en \u0026ldquo;Clients\u0026rdquo; y luego en \u0026ldquo;Create\u0026rdquo; para ingresar el nombre del \u0026ldquo;Client ID\u0026rdquo; (en este caso kasten) asegurándonos que el \u0026ldquo;Client Protocol\u0026rdquo; es \u0026ldquo;openid-connect\u0026rdquo;:\nPara luego ingresar al nuevo cliente desde el menu \u0026ldquo;Clients\u0026rdquo;.\nAhora configuraremos en detalle el cliente para que utilice OpenID y permita acceder a los usuarios o grupos, por tanto las configuraciones que se deben aplicar son las siguientes:\nA continuación explicaré cada uno de los campos configurados:\nEnabled = Habilita el cliente de Keycloak Always Display in Console = Para ver las sesiones en la consola de Keycloak Login Theme = Tipo de interfaz gráfica Client Protocol = Habilita el protocolo openid-connect que utilizaremos con K10 Access Type = Exige que se utilize una credencial para usar el cliente de Keycloak Standard Flow Enabled = Habilita las re-direcciones de OpenID para autenticación y autorización. Direct Access Grants Enabled = Acceso al usuario y contraseña e intercambio con Keycloak Service Accounts Enabled = En caso de usar cuentas de servicio OAuth 2.0 Device Authorization Grant Enabled = Soporte OAuth 2.0 Authorization Enabled = Autorizacion Granular habilitada Valid Redirect URIs = Las URI validas que se utilizan para ingreso y salida de la aplicación Web Origins = Configuracion de origenes CORS Backchannel Logout URL = Url de logout del cliente Backchannel Logout Session Required = Validar si el id de la sesion esta incluida en el logout Backchannel Logout Revoke Offline Sessions = Revoca acceso offline Browser Flow = Utilizará autenticacion con el browser Direct Grant Flow = Entregará directamente la sesion Ahora agregaremos un rol, para que este asociado a k10, ingresaremos en \u0026ldquo;Roles\u0026rdquo; dentro del mismo \u0026ldquo;Client\u0026rdquo; que ya configuramos y agregamos un nuevo rol de nombre \u0026ldquo;k10\u0026rdquo;:\nAhora ingresas en el rol recién creado luego en \u0026ldquo;Composite Roles\u0026rdquo; hacemos clic en \u0026ldquo;Client Roles\u0026rdquo; seleccionamos \u0026ldquo;kasten\u0026rdquo; y asignamos el nuevo rol \u0026ldquo;k10\u0026rdquo; en \u0026ldquo;Associated Roles\u0026rdquo;\nY por ultimo agregaremos por defecto el nuevo rol, clic en \u0026ldquo;Roles\u0026rdquo; y luego en el menú \u0026ldquo;Default Roles\u0026rdquo;, seleccionamos \u0026ldquo;kasten\u0026rdquo; en \u0026ldquo;Client Roles\u0026rdquo; y agregamos el nuevo rol \u0026ldquo;k10\u0026rdquo; a los roles por defecto:\nConfiguración Grupos Keycloak # Keycloak por defecto no tiene configurado los grupos en \u0026ldquo;Client Scopes\u0026rdquo;, es decir si configuramos la autenticación asociada a grupos, éste no funcionará, ya que kasten o la aplicación no podrá leer los grupos creados en Keycloak. Por tanto haremos clic en \u0026ldquo;Client Scopes\u0026rdquo; para luego hacer clic en \u0026ldquo;Create\u0026rdquo; e ingresamos el nombre \u0026ldquo;groups\u0026rdquo;, asegurándonos de usar el protocolo \u0026ldquo;openid-connect\u0026rdquo; y guardamos:\nIngresaremos en el reciente \u0026ldquo;Client Scope\u0026rdquo; creado \u0026ldquo;groups\u0026rdquo; y luego haremos clic en \u0026ldquo;Mappers\u0026rdquo; pare crear una nueva asociación clic en \u0026ldquo;Create\u0026rdquo;, ingresaremos el nombre \u0026ldquo;groups\u0026rdquo;, luego seleccionamos el \u0026ldquo;Mapper Type\u0026rdquo; que debe ser \u0026ldquo;Group Membership\u0026rdquo;, luego en \u0026ldquo;Token Claim Name\u0026rdquo; ingresamos \u0026ldquo;groups\u0026rdquo; y desactivamos \u0026ldquo;Full group path\u0026rdquo; para dejar las demás opciones activadas y guardamos:\nLuego hacemos clic en \u0026ldquo;Scope\u0026rdquo;, seleccionamos el \u0026ldquo;Client Roles\u0026rdquo; que es \u0026ldquo;kasten\u0026rdquo; para agregar el rol asignado \u0026ldquo;k10\u0026rdquo;:\nY por ultimo necesitamos agregar el nuevo \u0026ldquo;Client Scope\u0026rdquo; por defecto para que pueda ser leído por Kasten. En \u0026ldquo;Clients Scopes\u0026rdquo; seleccionar el menú \u0026ldquo;Default Client Scopes\u0026rdquo; y movemos \u0026ldquo;groups\u0026rdquo; a los scopes asignados por defecto:\nCreación de Grupos en Keycloak # Una excelente forma de administración de usuarios, es asociarlos a grupos que tengan ya los permisos o roles asociados para hacer mucho mas expedita la administración de éstos. Por tanto, una buena practica es utilizar la misma nomenclatura de Kasten para la creación de grupos. Haremos clic en \u0026ldquo;Groups\u0026rdquo; y luego en \u0026ldquo;New\u0026rdquo; para agregar el nombre del grupo, por ejemplo, \u0026ldquo;k10:admins\u0026rdquo; y guardamos.\nLuego seleccionamos y editamos el grupo, para seleccionar el menú \u0026ldquo;Role Mappings\u0026rdquo; y en \u0026ldquo;Client Roles\u0026rdquo; seleccionaremos \u0026ldquo;kasten\u0026rdquo; para luego asignar el rol \u0026ldquo;k10\u0026rdquo; como podemos ver en la siguiente imagen:\nSe pueden generar los grupos que sean necesarios y asignarle el rol anterior a cada uno de ellos como lo realizamos anteriormente.\nCreación de Usuarios en Keycloak # Ahora crearemos un usuario de administración para la gestión de Kasten K10 ya sea un solo cluster o utilizando Multi-Cluster Manager, por tanto, entraremos al menú \u0026ldquo;Users\u0026rdquo; e ingresamos la información solicitada y el grupo asociado, en este caso \u0026ldquo;k10:admins\u0026rdquo;, recuerda que en el caso de verificación de email debes tener configurado el servidor SMTP. De lo contrario solo lo habilitas:\nAlgo importante, opcionalmente, puedes solicitar al cliente que configure MFA para una mejor seguridad, solo debes agregarlo en \u0026ldquo;Required User Action\u0026rdquo;. Ahora asignaremos una contraseña al usuario, clic en \u0026ldquo;Credentials\u0026rdquo;, ingresamos la \u0026ldquo;password\u0026rdquo; necesaria, desactivamos la opción \u0026ldquo;Temporary\u0026rdquo; y clic en \u0026ldquo;Set Password\u0026rdquo;:\nEstamos en condiciones de comenzar a configurar la autenticación de Kasten K10 con Keycloak. En el siguiente post (Clic Aquí) revisaremos el paso a paso.\nPosts relacionados # Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 2 Kasten RBAC Multi-Tenant Multi-Cluster Keycloak – 3 Kasten K10 Authentik Como Integrar Active Directory con Kasten K10 y OpenShift Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam ","date":"26 de enero de 2022","externalUrl":null,"permalink":"/es/posts/kasten-rbac-multi-tenant-multi-cluster-keycloak/","section":"Blog","summary":"En este post, veremos la configuración de Role Based Access Control (RBAC) en conjunto con Kasten K10 para el acceso a uno o múltiples clusters protegidos por Kasten, esta dirigido tanto a clientes que manejen 1 o más clusters de cualquier distribución de kubernetes soportado por K10, como también a proveedores de servicios (SP o MSP) que ofrezcan el respaldo de contenedores de kubernetes con Kasten K10, con el objetivo de brindar un acceso controlado a los usuarios / clientes de acuerdo a los roles granulares necesarios por cada cluster u operación. Ademas utilizaremos una solución de Single Sign-On (SSO) usando OpenID en este caso, Keycloak, para la gestión centralizada de las credenciales de acceso ya sea para usuarios o grupos.","title":"Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1","type":"posts"},{"content":" Excelente tema estamos revisando, en el post anterior revisamos todo lo relacionado a la configuración de Keycloak para la administración de usuarios de forma centralizada a través de OpenID dejándolo preparado para la integración con Kasten K10 y Kasten K10 Multi-Cluster Manager. Por tanto en este post veremos paso a paso la configuración de los Clusterroles, Roles y grupos necesarios para gestión vía RBAC de Kasten K10.\nConfiguración Kasten Keycloak # \\\\\\* La idea de esta serie es explicar como generar los grupos, roles, clusterroles y demás recursos asociados a RBAC, sin la necesidad de estar modificando directamente en el cluster de kubernetes los permisos de usuario durante el tiempo, así toda la gestión de creación de usuario, grupos, asignación de grupos se realiza en Keycloak. ***\nDebemos conectarnos al cluster primario de Kubernetes donde se encuentra instalado Kasten K10 y procederemos a la configuración de autenticación con Keycloak, pero antes, necesitamos extraer el \u0026ldquo;Secret\u0026rdquo; desde nuestro \u0026ldquo;Client\u0026rdquo; kasten en el menú \u0026ldquo;Credentials\u0026rdquo; reemplazando en la variable \u0026ldquo;auth.oidcAuth.clientSecret\u0026rdquo;, (reemplazar SuperDuperClientSecret) y por supuesto reemplazando los valores por tus datos de DNS o IP, ejecutando el siguiente comando (por seguridad elimine parte del secret):\nhelm upgrade k10 kasten/k10 --namespace=kasten-io --set auth.oidcAuth.enabled=true --set auth.oidcAuth.providerURL=\u0026#34;https://auth.24xsiempre.com/auth/realms/kasten\u0026#34; --set auth.oidcAuth.redirectURL=\u0026#34;https://kasten.24xsiempre.com/\u0026#34; --set auth.oidcAuth.scopes=\u0026#34;groups profile email\u0026#34; --set auth.oidcAuth.groupClaim=\u0026#34;groups\u0026#34; --set auth.oidcAuth.prompt=\u0026#34;login\u0026#34; --set auth.oidcAuth.clientID=\u0026#34;kasten\u0026#34; --set auth.oidcAuth.clientSecret=\u0026#34;SuperDuperClientSecret\u0026#34; --set auth.oidcAuth.usernameClaim=\u0026#34;email\u0026#34; --reuse-values --set externalGateway.create=true ```bash Ahora veremos que significa cada uno de estas variables: - **--set auth.oidcAuth.enabled=true** / Habilitamos autenticación OpenID - **--set auth.oidcAuth.providerURL=\u0026#34;https://auth.24xsiempre.com/auth/realms/kasten\u0026#34;** / Url para Autenticarse - **--set auth.oidcAuth.redirectURL=\u0026#34;https://kasten.24xsiempre.com/\u0026#34;** / Url de aplicacion K10 - **--set auth.oidcAuth.scopes=\u0026#34;groups profile email\u0026#34;** / Client Scopes para validar - **--set auth.oidcAuth.groupClaim=\u0026#34;groups\u0026#34;** / Nombre del grupo de Client Scope - **--set auth.oidcAuth.prompt=\u0026#34;login\u0026#34;** / Mensaje de Login - **--set auth.oidcAuth.clientID=\u0026#34;kasten\u0026#34;** / Nombre del Cliente en el Realm creado. - **--set auth.oidcAuth.clientSecret=\u0026#34;SuperDuperClientSecret\u0026#34;** / Secret del cliente - **--set auth.oidcAuth.usernameClaim=\u0026#34;email\u0026#34;** / En caso de autenticacion de email - **--reuse-values** / Reusa valores ya configurados - **--set externalGateway.create=true** / Reconfigura servicio gateway en K10 para acceder remoto Un dato importante si ya tienes configurado un método de autenticación para Kasten, es mejor desactivarlo y luego ejecutar el comando anterior en caso de error. ## Acceso Usuarios Como ya tenemos todo configurado, la creación del usuario que realizamos en el post anterior, solo nos queda ingresar a la interfaz web de Kasten, recordemos el detalle del usuario: - Usuario: kastenadmin - Password: SuperDuperPassword o la que se haya aplicado - Grupo: k10:admins Ahora solo ingresaremos a la Url de Kasten en mi caso https://kasten.24xsiempre.com/k10/#/ y nos redirigirá a el formulario de ingreso de Keycloak en el realm de Kasten, ingresamos las credenciales: Y podremos observar que tenemos un ingreso exitoso y con todos los permisos ya que pertenecemos al grupo \u0026#34;k10:admins\u0026#34; y no tuvimos que editar ningún ClusterRole o Roles. Para confirmar los permisos, es posible validarlos gráficamente ya sea viendo \u0026#34;permissions\u0026#34; \u0026#34;unrestricted\u0026#34; o entrando al cluster primario, luego \u0026#34;Cluster Settings\u0026#34; , después \u0026#34;Support\u0026#34; y por ultimo clic en \u0026#34;View Current User Details\u0026#34; y podrás visualizar todos los permisos de ese usuario y al grupo que pertenece: Hasta aquí todo bien, pero que pasa si al usuario \u0026#34;kastenadmin\u0026#34; lo cambiamos de grupo? Entraremos nuevamente a Keycloak y cambiamos el grupo \u0026#34;k10:admins\u0026#34; por \u0026#34;k10:basic\u0026#34; E ingresamos nuevamente a Kasten veremos lo siguiente: El usuario \u0026#34;kastenadmin\u0026#34; ya no pertenece a \u0026#34;k10:admins\u0026#34; y ahora pertenece a \u0026#34;k10:basic\u0026#34; el cual no se encuentra configurado con su respectivo ClusterRoleBinding, RoleBinding asociado a algún ClusterRole o Role. ## Creación de Roles de Acceso en Kasten K10 Como vimos anteriormente, tenemos configurado el cluster primario de Kasten K10 como también kasten Multi-Cluster Manager, comenzaremos revisando el acceso sólo al cluster primario sin la necesidad de acceder a los roles del Multi-Cluster. ### Usuario Administrador Asi en caso de no necesitar Multi-Cluster Manager es posible administrar los usuarios con Keycloak. Por tanto crearemos un grupo en Keycloak para acceder al cluster de nombre \u0026#34;k10:solo\u0026#34; y lo asociaremos al usuario \u0026#34;kastenadmin\u0026#34; Y ahora vía SSH listaremos los ClusterRoles: ```bash kubectl get clusterrole | grep k10 ```json Generaremos un archivo yaml con el siguiente contenido: ```text nano k10solo.yaml ```yaml ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: k10-k10-solo roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: k10-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: k10:solo ```bash Y luego lo aplicamos con el comando: ```bash kubectl apply -f k10solo.yaml ```bash Confirmaremos la creación del ClusterRoleBinding listando con el comando: ```bash kubectl get clusterrolebindings | grep k10 ```bash Y si nuevamente ingresamos a Kasten K10 podremos validar que solo tenemos acceso al cluster de producción como administrador, ahora por que tengo acceso como administrador? en la linea **5** del archivo yaml que generamos se encuentra la referencia al ClusterRole \u0026#34;k10-admin\u0026#34; lo cual nos garantiza el rol. Al acceder veremos que tenemos acceso a todo, excepto por el siguiente error: Lo que nos esta diciendo Kasten K10 es que no tiene permisos sobre el namespace \u0026#34;kasten-io\u0026#34; para consultar o listar los deployments y saber el estado de los servicios, para ellos debemos agregar el grupo \u0026#34;k10:solo\u0026#34; en el Role \u0026#34;k10-ns-admin\u0026#34; que se encuentra en dicho namespace. Para listar el rol: ```bash kubectl get roles -n kasten-io ```bash Siempre existen varias formas de editar estos roles, puedes editarlo directamente con el comando \u0026#34;kubectl edit roles k10-ns-admin -n kasten-io\u0026#34; o hacerlo con el siguiente yaml: ```text nano ns-admin-k10solo.yaml ```bash ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: k10-k10-ns-solo namespace: kasten-io roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: k10-ns-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: k10:solo ```bash ```bash kubectl apply -f ns-admin-k10solo.yaml ```bash Confirmaremos la creación del RoleBinding listando con el comando ```bash kubectl get rolebindings -n kasten-io ```bash Y ahora validamos nuevamente los permisos y que no aparezca el error de los estados de servicios de Kasten K10: Y ya tenemos todo de un excelente color :). Ahora que pasa si quiero un usuario que pueda ejecutar pero que no pueda modificar las configuraciones? ### Usuario Operador Como ya hemos visto anteriormente, vamos a crear un grupo en keycloak de nombre \u0026#34;k10:operador\u0026#34; y lo asignamos como un único grupo nuevamente al usuario \u0026#34;kastenadmin\u0026#34;. Que es lo que necesita un operador, por ejemplo, que pueda ver todas las aplicaciones, pueda ver todos las políticas de respaldo como también los reportes generados automáticamente, a su vez, que tenga acceso para la creación, edición de política de respaldo pero que **NO** pueda eliminar algún recurso o editar alguna configuración. Por tanto, vamos a crear un ClusterRole que nos permita tener los permisos necesarios para el rol de \u0026#34;Operador\u0026#34;, Crearemos el archivo con su respectivo contenido: ```text nano k10operadorclusterrole.yaml ```bash ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: k10-operador rules: - apiGroups: - actions.kio.kasten.io - apps.kio.kasten.io - config.kio.kasten.io - reporting.kio.kasten.io - vault.kio.kasten.io resources: - \u0026#39;*\u0026#39; verbs: - get - list - patch - update - watch - create - apiGroups: - cr.kanister.io resources: - \u0026#39;*\u0026#39; verbs: - \u0026#39;*\u0026#39; - apiGroups: - \u0026#34;\u0026#34; resources: - namespaces verbs: - create - get - list ```bash Y aplicamos el archivo: kubectl apply -f k10operadorclusterrole.yaml Como podemos ver en el archivo, el usuario clusterrole de operador **no tiene permisos de eliminación**, validamos la creación del clusterrole: ```bash kubectl get clusterrole | grep k10 ```json Ahora generamos el clusterrolebinding para asociarlo con nuestro grupo de usuarios \u0026#34;k10:operador\u0026#34; ```text nano k10operadorbind.yaml ```yaml ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: k10-k10-operador roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: k10-operador subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: k10:operador ```bash Y aplicamos el archivo: ```bash kubectl apply -f k10operadorbind.yaml ```bash Validamos: ```bash kubectl get clusterrolebindings | grep k10 ```json Y por último, como va a poder acceder pero no eliminar, también lo agregaremos al \u0026#34;ns-admin\u0026#34;: ```text nano k10operadornsadmin.yaml ```bash ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: k10-k10-ns-operador namespace: kasten-io roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: k10-ns-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: k10:operador ```bash Validamos la creación: ```bash kubectl get rolebinding -n kasten-io Validamos acceso a Kasten K10:\nPor ejemplo si el usuario desea eliminar una Política de Respaldo tendrá el siguiente mensaje:\nPero si desea crear una política de respaldo si podrá realizarlo:\nO si quisiera borrar un \u0026ldquo;Location Profile\u0026rdquo; no podrá ya que no tiene el permiso para ello y el botón de eliminar se encuentra deshabilitado\nCon esto queda demostrado que puedes generar los recursos de RBAC asociados a grupos administrando los usuarios directamente desde Keycloak, sin la necesidad de estar creando usuarios locales o editando los clusterroles / clusterrolebindings cada vez que un usuario necesite acceso a la plataforma de Kasten. Pero aun no hemos terminado, nos falta revisar el RBAC de Kasten Multi-Cluster Manager, que lo veremos en el siguiente post, Clic Aqui!\nPosts relacionados # Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1 Kasten RBAC Multi-Tenant Multi-Cluster Keycloak – 3 Kasten K10 Authentik Como Integrar Active Directory con Kasten K10 y OpenShift ","date":"26 de enero de 2022","externalUrl":null,"permalink":"/es/posts/kasten-rbac-multi-tenant-multi-cluster-keycloak-parte-2/","section":"Blog","summary":"Excelente tema estamos revisando, en el post anterior revisamos todo lo relacionado a la configuración de Keycloak para la administración de usuarios de forma centralizada a través de OpenID dejándolo preparado para la integración con Kasten K10 y Kasten K10 Multi-Cluster Manager. Por tanto en este post veremos paso a paso la configuración de los Clusterroles, Roles y grupos necesarios para gestión vía RBAC de Kasten K10.","title":"Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 2","type":"posts"},{"content":"","date":"13 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/red-hat/","section":"Etiquetas","summary":"","title":"Red-Hat","type":"tags"},{"content":"","date":"13 octubre 2021","externalUrl":null,"permalink":"/en/tags/red-hat-backup/","section":"Tags","summary":"","title":"Red-Hat-Backup","type":"tags"},{"content":"","date":"13 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/red-hat-virtualization/","section":"Etiquetas","summary":"","title":"Red-Hat-Virtualization","type":"tags"},{"content":"","date":"13 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/respaldo-red-hat/","section":"Etiquetas","summary":"","title":"Respaldo-Red-Hat","type":"tags"},{"content":"","date":"13 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/respaldo-rhv/","section":"Etiquetas","summary":"","title":"Respaldo-Rhv","type":"tags"},{"content":"","date":"13 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/rhv/","section":"Etiquetas","summary":"","title":"Rhv","type":"tags"},{"content":"","date":"13 octubre 2021","externalUrl":null,"permalink":"/en/tags/rhv-backup/","section":"Tags","summary":"","title":"Rhv-Backup","type":"tags"},{"content":" Tremenda noticia desde Veeam! Ahora soporta una nueva plataforma de virtualización, Red Hat Virtualization, con el objetivo de proteger las maquinas virtuales de una manera fácil y aprovechando la integración de las nuevas API\u0026rsquo;s CBT que se han implementado en RHV. En este post veremos como desplegar Veeam for Red Hat Virtualization integrado con Veeam Backup \u0026amp; Replication revisando las características y dependencias necesarias para la protección completa de RHV.\nPasos Iniciales # Como es de costumbre siempre debemos ir a la documentación oficial de la solución, en este caso Veeam Backup for RHV 1.0\nManual: https://helpcenter.veeam.com/docs/vbrhv/userguide/overview.html?ver=10 Release Notes: https://www.veeam.com/veeam_backup_for_rhv_1_0_release_notes_rn.pdf Descarga de Veeam RHV: https://www.veeam.com/backup-red-hat-virtualization-download.html Algo muy importante a señalar en esta versión de Veeam Backup for RHV, se encuentra en formato BETA publico, es decir, puedes descargarlo, implementarlo con soporte oficial de Veeam. Necesitas licenciamiento valido en tu VBR ya que tiene integración con Veeam Universal License. Por supuesto puedes utilizar licencias trial.\nRequerimientos # Para alojar nuestros respaldos necesitamos un repositorio con Veeam Backup \u0026amp; Replication:\nVeeam Backup \u0026amp; Replication 11a (11.0.1.1261) o superior Red Hat Virtualization 4.4.8 o superior Hardware Virtual para Veeam RHV\n4 CPU cores + 1 por cada tarea concurrente (se puede agregar mas si es necesario) 4 GB RAM mínimo (se puede agregar mas si es necesario) 64 GB Espacio Se recomienda que en caso de que se incremente la cantidad de CPU paralelamente se incremente la cantidad de RAM, es decir, si el appliance tiene 8 CPU cores, también debe tener 8 GB de RAM y así sucesivamente.\nRed\nDHCP (luego podremos cambiar la dirección IP desde la Interfaz) Puertos\nhttps://helpcenter.veeam.com/docs/vbrhv/userguide/used_ports.html?ver=10 Discos de Maquinas Virtuales\nEsta opción es importante para aprovechar la utilización de API CBT en las maquinas que corren en Red Hat Virtualization, las maquinas que se protegerán en sus discos deben tener habilitada la opción \u0026quot; Enable Incremental Backup\u0026quot;\nYa que es una limitante de la plataforma de virtualizacion, es importante revisar:\nhttps://helpcenter.veeam.com/docs/vbrhv/userguide/backup_job_prerequisites.html?ver=10 Instalación Veeam Backup for RHV # Como ya hemos descargado el appliance, debemos copiarlo a un host del cluster a través de ssh, en mi caso utilizo WinSCP y lo dejare en la ruta /tmp/veeam/\nLuego asignaremos permisos para que el host de RHV pueda leer los archivos (recuerda que los tengo en la ruta /tmp/veeam) del appliance con los comandos:\nchmod -R 755 veeam/ chown 36:36 -R veeam/ ls -ltrh veeam/ Como se ve en la imagen anterior, el usuario vdsm y el grupo kvm ahora tienen acceso a los archivos, por tanto, es el momento de importar el appliance a la consola de Red Hat Virtualization. Ingresaremos a Compute -\u0026gt; Virtual Machines y en el menú despegable seleccionaremos la opción \u0026quot; Import\u0026quot;\nLuego Seleccionamos el Datacenter, Source, que debe ser \u0026quot; Virtual Appliance\u0026quot;, el host de RHV donde subimos los archivos del appliance y por ultimo ingresar la ruta de los archivos, en este caso, /tmp/veeam/ y realizamos clic en \u0026quot; Load\u0026quot; nos mostrara el nombre del appliance para seleccionarlo y pasarlo a \u0026quot; Virtual Machines to Import\u0026quot;\nLuego clic en \u0026ldquo;Next\u0026rdquo; para seleccionar configuraciones de CPU, Allocation, etc, las puedes dejar por defecto y hacer clic en \u0026ldquo;OK\u0026rdquo;\nCon lo anterior solo debemos esperar a que termine la tarea de importación del appliance, lo puedes seguir en \u0026ldquo;Tasks\u0026rdquo; o directamente en la maquina virtual:\nAhora solo nos queda encender la maquina, seleccionamos nuestra maquina \u0026ldquo;veeam_rhv_proxy_beta_vm_1.0.1488\u0026rdquo; o el nombre que hayas ingresado y clic en \u0026quot; Run\u0026quot;\nSi quieres ver el booteo, seleccionas la maquina virtual y haces clic en \u0026ldquo;Console\u0026rdquo; para que descargue un utilitario para ver la maquina virtual:\nAutomáticamente se descarga un archivo \u0026quot; console.vv\u0026quot; lo ejecutas y podrás tener acceso a la maquina virtual:\n\\\\ En caso de que no se asigna la IP por DHCP revisa con el administrador de RHV o Reiniciar el appliance**\nConfiguración Veeam Backup for RHV # Como pudimos observar en la ultima imagen, nos indica la dirección IP que se asigno por DHCP, por tanto, debemos ingresar vía HTTPS a esa dirección:\nEl usuario y Contraseña para el primer acceso es \u0026quot; veeam\u0026quot; e ingresamos a Veeam for Red Hat Virtualization\nPor supuesto seleccionamos la opción \u0026ldquo;Install\u0026rdquo; para aceptar EULA e ingresar las configuraciones solicitadas:\nLuego de hacer clic en \u0026ldquo;Next\u0026rdquo; ingresas la nueva contraseña\nEn esta opción puedes asignarle nombre del server, dirección IP Fija y dns, por ejemplo:\nNext y veremos el resumen de la configuración para terminar haciendo clic en \u0026ldquo;Finish\u0026rdquo;\nAhora esperar 60 segundos para que se aplique la configuración e internamente se reinicien servicios\nLuego ingresamos vía fqdn o IP para ingresar nuestras nuevas credenciales:\nActualización Veeam Backup for RHV # Ya en el Dashboard, debemos hacer clic en el icono de configuración (engranaje) en la parte superior derecha\nY seleccionaremos \u0026ldquo;Appliance Settings\u0026rdquo;, Aquí podremos configurar lo necesario del appliance, en este caso configuraremos el \u0026ldquo;Time Zone\u0026rdquo; y luego aplicaremos actualizaciones\nLuego clic en \u0026ldquo;Updates\u0026rdquo; para luego hacer clic en \u0026ldquo;Check and view updates\u0026rdquo;\nAbrirá otra pestaña y podrás chequear si hay actualizaciones disponibles o no, ya sea del sistema operativo como también de Veeam Backup for RHV\nSeleccionas todas las actualizaciones e instalas las actualizaciones\nCierra la pestaña de actualizaciones y pasaremos a configurar Veeam Backup for RHV con el hipervisor y Veeam Backup \u0026amp; Replication.\nConfiguración Veeam Backup \u0026amp; Replication # Nuevamente vamos al icono de configuración (engranaje) y seleccionamos \u0026ldquo;Manage Backup Server\u0026rdquo;\nClic en \u0026quot; Add\u0026quot; e ingresas la información de Veeam Backup \u0026amp; Replication, para luego hacer clic en \u0026quot; OK\u0026quot;\nY nos mostrará la configuración aplicada\nConfiguración Red Hat Virtualization Manager # Ahora haremos clic en \u0026quot; Manage Virtualization Manager\u0026quot; y luego en \u0026quot; Add\u0026quot; e ingresar los datos, algo muy importante es que todo debe estar configurado para usar DNS\nEl usuario siempre debe ser uno administrativo de forma \u0026ldquo;admin@internal\u0026rdquo; y en el caso de que la primera vez no reconozca el certificado, solo debes reintentarlo.\nAl hacer clic en \u0026quot; OK\u0026quot; nos indicara si deseamos aceptar el certificado y proceder\nY nos mostrara la versión de RHV y la configuración aplicada\nAhora. volvemos al \u0026ldquo;Dashboard\u0026rdquo; veremos que reconoce las maquinas virtuales existentes y la configuración de los repositorio de Veeam Backup \u0026amp; Replication:\nCreación Jobs de Respaldo # Debemos seleccionar el menu \u0026ldquo;Jobs\u0026rdquo; dentro del \u0026ldquo;Dashboard\u0026rdquo; para ingresar al panel de Jobs, por supuesto no tenemos ninguno configurado\nClic en \u0026ldquo;Add\u0026rdquo; e ingresamos el nombre del Job de respaldo:\nLuego de hacer clic en \u0026ldquo;Next\u0026rdquo; pasaremos a agregar maquinas virtuales a proteger\nHaremos clic en \u0026ldquo;Add\u0026rdquo; y seleccionaremos las maquinas a respaldar\nY luego de hacer clic en \u0026ldquo;Add\u0026rdquo; pasaremos a la configuración del repositorio donde se alojaran los respaldos, en este paso, solo debes elegir el repositorio de Veeam Backup \u0026amp; Replication y los puntos de restauración\nLuego pasamos al agendamiento haciendo clic en \u0026ldquo;Next\u0026rdquo; e ingresamos lo necesario\nY por ultimo, veremos el resumen de la configuración del job e iniciaremos el job de respaldo después de la creación seleccionando \u0026ldquo;Run job when I click Finish\u0026rdquo;\nY veremos las estadísticas de respaldo:\nY en nuestra consola de Veeam Backup \u0026amp; Replication veremos el job de respaldo y si esta en ejecución o no:\nY por supuesto la finalización del respaldo:\nY si quieres comprobar un respaldo incremental ejecutar el Job y en las estadísticas obtendrás\nRecuperación de Archivos o Maquina Virtual # Las recuperaciones se pueden realizar tanto desde Veeam Backup \u0026amp; Replication como también desde la interfaz web de Veeam Backup for RHV, por ejemplo puedes realizar todas las recuperaciones desde VBR como se muestra en la siguiente imagen:\nY desde veeam Backup for RHV, haciendo clic en \u0026ldquo;Protected VMs\u0026rdquo;, seleccionando la maquina virtual podrás ver los puntos de restauración como también las dos opciones iniciales para recuperar la maquina completa o solo discos:\nAl hacer clic en \u0026quot; Restore\u0026quot; permite recuperar la maquina virtual hacia la misma ubicación u otra con diferentes configuraciones y en el caso de utilizar \u0026quot; Disk Restore\u0026quot; es posible mapear el disco que deseas recuperar a la maquina virtual que necesites utilizar en ese momento. Para recuperar la maquina completa nos mostrara lo siguiente\nDonde podremos seleccionar el punto de restauración utilizando el icono \u0026ldquo;Point\u0026rdquo;\nSeleccionamos el punto que deseamos usar y pasamos a seleccionar el modo de restauración, en este caso utilizaré \u0026ldquo;Restore to Original Location\u0026rdquo;\nClic en \u0026ldquo;Next\u0026rdquo; e ingresamos la razón de la restauración\nNos indicará que la maquina virtual actual sera eliminada de la infraestructura virtual para proceder a recuperar:\nY seleccionaremos que encienda la VM después de recuperar:\nY veremos las estadísticas de recuperación:\nRecomendaciones # Muy importante leer las limitaciones de los discos, ya que para poder usar respaldo incrementales nativos desde Red Hat Virtualization, éstos, debe estar en formato QCOW2 el cual permite la utilización de la API CBT como se indica\nhttps://helpcenter.veeam.com/docs/vbrhv/userguide/backup_job_prerequisites.html?ver=10 Ademas en caso de cualquier problema de comunicación entre las soluciones puedes revisar\nhttps://helpcenter.veeam.com/docs/vbrhv/userguide/troubleshooting.html?ver=10 Y para los casos cuando el respaldo incremental esta deshabilitado en todo el sistema o se poseen discos sin la habilitación del respaldo incremental, la opción \u0026ldquo;Enable Incremental Backup\u0026rdquo; debes visitar\nhttps://www.veeam.com/kb4208 Por ultimo si no habilitas la opción anterior, de igual manera puedes proteger tus maquinas virtuales con Veeam Backup for Red Hat Virtualization.\nPosts relacionados # Veeam Citrix Hypervisor / Xenserver Protegiendo Oracle KVM con Veeam Proxmox Lab con ZimaBlade Veeam + Kasten ","date":"13 de octubre de 2021","externalUrl":null,"permalink":"/es/posts/veeam-backup-for-red-hat-virtualization/","section":"Blog","summary":"Tremenda noticia desde Veeam! Ahora soporta una nueva plataforma de virtualización, Red Hat Virtualization, con el objetivo de proteger las maquinas virtuales de una manera fácil y aprovechando la integración de las nuevas API’s CBT que se han implementado en RHV. En este post veremos como desplegar Veeam for Red Hat Virtualization integrado con Veeam Backup \u0026 Replication revisando las características y dependencias necesarias para la protección completa de RHV.","title":"Veeam Backup for Red Hat Virtualization","type":"posts"},{"content":"","date":"13 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/veeam-backup-for-rhv/","section":"Etiquetas","summary":"","title":"Veeam-Backup-for-Rhv","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/baas/","section":"Etiquetas","summary":"","title":"Baas","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/clave/","section":"Etiquetas","summary":"","title":"Clave","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/draas/","section":"Etiquetas","summary":"","title":"Draas","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/performance/","section":"Etiquetas","summary":"","title":"Performance","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/registro/","section":"Etiquetas","summary":"","title":"Registro","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/rendimiento/","section":"Etiquetas","summary":"","title":"Rendimiento","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/vcloud/","section":"Etiquetas","summary":"","title":"Vcloud","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/categories/vcloud-director/","section":"Categorías","summary":"","title":"Vcloud-Director","type":"categories"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/vcloud-director/","section":"Etiquetas","summary":"","title":"Vcloud-Director","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/vcsp/","section":"Etiquetas","summary":"","title":"Vcsp","type":"tags"},{"content":" Una de las plataformas más utilizadas para ofrecer servicios de gestión remota, respaldo, recuperación ante desastres, entre otros es Veeam Cloud Connect con Veeam Service Provider Console, los cuales habilitan a proveedores de servicios ofrecer múltiples opciones de protección de datos. Ademas existe Veeam Cloud Connect for Enterprise que permite a grandes empresas ofrecer internamente servicios de acuerdo a las necesidades de su negocio. En este post revisaremos una configuración simple para mejorar el rendimiento en la recepción de los datos.\nPasos Iniciales # Como siempre debemos visitar la documentación oficial y ademas revisar las nuevas actualizaciones, como por ejemplo la ultima versión de Veeam Service Provider Console que esta en su versión 6, para descargar la ISO debes ingresar a Veeam.com y solicitar la descarga, en el siguiente link tienes los release notes de la ultima versión, como también las direcciones de los manuales de las soluciones:\nRelease Notes Veeam Service Provider Console v6: https://www.veeam.com/vspc_6_0_release_notes_rn.pdf Manual Veeam Service Provider Console v6: https://helpcenter.veeam.com/docs/vac/provider_user/about.html?ver=60 Manual Veeam Cloud Connect: https://helpcenter.veeam.com/docs/backup/cloud/cloud_overview.html?ver=110 Aquí veremos una configuración a nivel de registro con su respectiva comparativa de antes y después del cambio sobre un ambiente que usa Veeam Cloud Connect y Veeam Service Provider Console, sobre VMware v7.0U2 a través de Internet en mi laboratorio.\nAmbiente de Prueba # Muy simple, realice la instalación y configuración para laboratorio de solo 1 maquina virtual, es decir, All In One, con las siguientes versiones:\nVeeam Cloud Connect v11 Veeam Service Provider Console v6 Veeam Backup \u0026amp; Replication 11a (Tenant para Respaldo de VM) Recursos Maquinas Virtual para VCC y VSPC AIO ( Por ningún motivo usar para producción)\n8 vCPU 12 GB RAM Disco S.O 150 GB Disco Repo ReFS 500GB Como la configuración es AIO (para lab), todos los roles esta desplegados en la misma consola, Cloud Gateway Repositorio, etc.\nAdemas es muy importante señalar que este cambio de configuración a nivel del registro también aplica para ambientes que tengan Veeam Cloud Connect / vCloud Director y/o el respectivo plugin para vCloud Director que provees acceso al portal de autoatención desde Veeam Enterprise Manager. Por supuesto también aplica para V eeam Cloud Connect for Enterprise. Ya que en mi caso solo tengo 2 ESXi y vCenter.\nPruebas antes del Cambio # En este paso realizaremos dos pruebas realizando respaldos Full de una maquina virtual y también de múltiples maquinas virtuales con respaldos Full apuntando directo al repositorio de Veeam Cloud Connect gestionado con Veeam Service Provider Console.\nLa configuración del Job de respaldo en mi ambiente de Veeam Backup \u0026amp; Replication Local es por defecto y solo cambiamos repositorio que este caso sera el de Veeam Cloud Connect que configuramos anteriormente:\nY luego ejecutamos las tareas de respaldos utilizando el método Active Full para ambos Jobs y esperamos que terminen\nEstadísticas Job con Múltiples Maquinas Virtuales\nY si revisamos la consola desde la consola de Veeam Cloud Connect veremos las estadísticas para el Job de una maquina:\nY las estadísticas para el Job de múltiples maquinas virtuales:\nRevisión de Tareas de Respaldo # Como podemos ver en las estadísticas anteriores tenemos lo siguiente:\nNombre Job Estado Inicio Término Datos Enviados Datos Recibidos Tasa Procesamiento DC → VCSP (Active Full) Éxito 07-10-2021 20:23 07-10-2021 20:30 34,4 KB 7.8 GB 60 MB/s Múltiples VM → VCSP (Active Full) Éxito 07-10-2021 22:22 07-10-2021 22:50 227,4 KB 49.6 GB 69 MB/s En la tarea de la maquina virtual podremos ver que la duración del respaldo Full fue de aproximadamente 7 minutos y el \u0026ldquo;Processing Rate\u0026rdquo; de 60 MB/s. Para el Job con múltiples maquinas, la duración del respaldo Full fue de aproximadamente 28 minutos y el \u0026ldquo;Processing Rate\u0026rdquo; de 69 MB/s:\nJob Duración Processing Rate DC → VCSP (Active Full) 6.44 minutos 60 MB/s Múltiples VM → VCSP (Active Full) 28 minutos 69 MB/s Por tanto de acuerdo a las configuraciones por defecto de Veeam Cloud Connect y traficando los datos via internet, que en total suman alrededor de 57.4 GB funciona correctamente.\nConfiguración Clave de Registro # En esta etapa revisaremos el comportamiento de asignación de cuotas de espacio cuando se esta realizando el respaldo hacia un repositorio cloud en Veeam Cloud Connect. Esto aplica para los respaldos que se estén realizando sobre vCloud director con VCC también.\nEl comportamiento con respecto a la asignación de cuotas de espacio que usa VeeamAgent.exe, cada 10 o 15 segundos asigna 512MB para almacenar datos, si en caso de que este se supera, tratara de asignar más espacio y se escribira en el log \u0026ldquo;Storage size quota exceeded. Waiting for quota increase\u0026rdquo; lo que podría generar un cuello de botella cuando los datos son transferidos rápidamente.\nPara este tipo de caso de uso o ambientes que revisamos anteriormente es que existe una clave de registro para agregar y cambiar la lógica del mecanismo la cual se debe aplicar en:\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Veeam\\Veeam Backup and Replication ```text Y debemos agregar la clave **DWORD**: ```text CloudConnectQuotaAllocationMode Para esta clave de registro existen 3 opciones:\n0 = Valor y comportamiento por defecto de 512MB cada 10 segundos. 1 = VeeamAgent.exe solicita el espacio necesario sin la necesidad de esperar los 10 segundos. 2 = Utiliza una combinación de los valores anteriores. Por tanto para nuestro caso utilizaremos el valor 1 para configurar la clave y quedaría de la siguiente forma en nuestro servidor de Veeam Cloud Connect o Veeam VBR que estén usando con vCloud Director:\nY luego del solo reiniciar el servicio \u0026quot; Veeam Backup Service\u0026quot; del servidor donde están los servicios de Veeam Cloud Connect o Veeam VBR con vCloud Director\nResultados # Después de reiniciar el servicio y ejecutar nuevamente los Jobs, forzando Active Fulls para cada uno de ellos, podremos ver lo siguiente:\nUna maquina virtual\nMúltiples maquinas virtuales:\nEstadísticas desde la Consola de Veeam Cloud Connect:\nSi revisamos los datos después del cambio efectuado el resumen seria el siguiente:\nNombre Job Estado Inicio Término Datos Enviados Datos Recibidos Tasa Procesamiento DC → VCSP (Active Full) Éxito 07-10-2021 21:47 07-10-2021 21:51 29.2 KB 7.8 GB 170 MB/s Múltiples VM → VCSP (Active Full) Éxito 07-10-2021 22:58 07-10-2021 23:11 206.1 KB 49.6 GB 175 MB/s Y el detalle:\nJob Duración Processing Rate DC → VCSP (Active Full) 4.12 minutos 170 MB/s Múltiples VM → VCSP (Active Full) 13 minutos 175 MB/s Diferencias de Tiempo y Procesamiento # Por tanto en relación a los tiempos de ejecución y transferencia de archivos como también la tasa de procesamiento después de la aplicación de la clave de registro obtuvimos una mejora en el rendimiento muy notable, por ejemplo:\nEl \u0026ldquo;Processing Rate\u0026rdquo; inicial de una maquina virtual antes del cambio era de 60 MB/s y después de la aplicación de la clave obtuvimos un incremento a 170 MB/s El \u0026ldquo;Processing Rate\u0026rdquo; inicial de múltiples maquinas virtuales antes del cambio era de 69 MB/s y después de la aplicación de la clave obtuvimos un incremento a 175 MB/s La duración del respaldo de una maquina virtuale antes del cambio era de 6.44 minuto s y después de la aplicación de la clave bajó a 4.12 minutos La duración del respaldo de múltiples maquinas virtuales antes del cambio era de 28 minuto s y después de la aplicación de la clave bajó a 13 minutos Así, vemos incrementado nuestro rendimiento en 2 o 3 veces en este caso, lo cual podría ser superior si se cuenta con infraestructura dedicada con su respectiva arquitectura para este tipo de servicios.\nConclusión # Como vimos, la aplicación de esta clave de registro nos permite mejorar el rendimiento de nuestros respaldos hacia repositorios en Veeam Cloud Connect o con la integración de vCloud Director, como siempre es muy aconsejable revisar el caso de uso para cada uno de los ambientes que se intervengan y que posean velocidades de subida de datos rápidas o soluciones internas.\nPosts relacionados # Veeam Capacity Tier Oracle Cloud Object Storage Veeam Backup para AWS v3 Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam Veeam Hardened (Immutable) Repository ","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/posts/veeam-cloud-connect-performance/","section":"Blog","summary":"Una de las plataformas más utilizadas para ofrecer servicios de gestión remota, respaldo, recuperación ante desastres, entre otros es Veeam Cloud Connect con Veeam Service Provider Console, los cuales habilitan a proveedores de servicios ofrecer múltiples opciones de protección de datos. Ademas existe Veeam Cloud Connect for Enterprise que permite a grandes empresas ofrecer internamente servicios de acuerdo a las necesidades de su negocio. En este post revisaremos una configuración simple para mejorar el rendimiento en la recepción de los datos.","title":"Veeam Cloud Connect Performance","type":"posts"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/veeam-cloud/","section":"Etiquetas","summary":"","title":"Veeam-Cloud","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/veeam-cloud-connect/","section":"Etiquetas","summary":"","title":"Veeam-Cloud-Connect","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/veeam-service-provider-console/","section":"Etiquetas","summary":"","title":"Veeam-Service-Provider-Console","type":"tags"},{"content":"","date":"8 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/veeam-vcsp/","section":"Etiquetas","summary":"","title":"Veeam-Vcsp","type":"tags"},{"content":"","date":"6 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/como-instalar-veeam-agent-solaris/","section":"Etiquetas","summary":"","title":"Como-Instalar-Veeam-Agent-Solaris","type":"tags"},{"content":"","date":"6 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/solaris/","section":"Etiquetas","summary":"","title":"Solaris","type":"tags"},{"content":"","date":"6 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/solaris-veeam-console/","section":"Etiquetas","summary":"","title":"Solaris-Veeam-Console","type":"tags"},{"content":" En este post revisaremos una de las funcionalidades nuevas en la ultima versión de Veeam Backup \u0026amp; Replication 11a que se ha lanzado recientemente e incluye la gestión desde la consola de Veeam Backup \u0026amp; Replication para los agentes Unix, Veeam Agent for Solaris y Veeam Agent for AIX\nDonde descargar Veeam 11a # Como es de costumbre, siempre revisaremos la documentación oficial para saber las novedades de esta nueva versión como también cualquier limitación relacionada a algunos ambientes si es que los hubiera, para ellos visitaremos las siguientes direcciones:\nVeeam Backup \u0026amp; Replication 11a\nhttps://www.veeam.com/kb4215 Veeam ONE 11a\nhttps://www.veeam.com/kb4197 Ademas se han lanzado nuevas versiones de las otras soluciones de veeam, como por ejemplo, Veeam Backup para AWS v4, para mayor información de las demás actualizaciones visiten veeam.com\nComo vemos en el KB4215 indica la gestión centralizada de agentes Unix, Solaris y AIX, por tanto veremos como realizar la instalación, configuración y gestión de los agentes a través de la consola VBR y su respectivo protection group.\nProtection Group # En el menu de Inventory y luego en Physical Infrastructure, crearemos un nuevo Protection Group y luego de asignarle el nombre, seleccionaremos \u0026ldquo;Computers with pre-installed agents\u0026rdquo;\nLuego de seleccionar la opción anterior, pasaremos a seleccionar \u0026ldquo;Export Path\u0026rdquo; e ingresaremos la carpeta donde dejaremos los agentes (en mi caso solo Solaris - Intel, pero puedes seleccionar el que sea necesario) para la configuración posterior y seleccionamos \u0026ldquo;Apply\u0026rdquo;\nY nos mostrará el Status\nRevisión de Instaladores # Ahora. que finalizamos la configuración, iremos a la carpeta que seleccionamos, en mi caso lo deje en el escritorio del servidor, para ver los archivos que se exportaron\nExisten 3 archivos (en mi caso solo para solaris - intel)\nreadme.txt Unix.xml VeeamAgentSolaris Donde readme.txt nos indicara paso a paso como realizar la instalación de Veeam Agent for Solaris Unix.xml, donde el nombre esta relacionado al grupo de protección y contiene la configuración de acceso a VBR y por ultimo el paquete de instalación de Veeam Agent for Solaris. Este paquete lo descomprimimos y copiaremos con tu herramienta de preferencia (en mi caso WinSCP) mlocate-0.26-i386.pkg VeeamAgent-3.0.0.561-i386.pkg al servidor Solaris que deseamos proteger.\nY realizaremos los que indica readme.txt\nInstalación y Configuración Veeam Agent for Solaris # Ya tenemos los archivos copiados, seguiremos los pasos indicados en readme.txt e instalaremos los paquetes, comenzaremos con mlocate usando el comando\npkgadd -G -d mlocate-0.26-i386.pkg ```json Y luego la instalación de Veeam Agent for Solaris, con el comando ```text pkgadd -G -d VeeamAgent-3.0.0.561-i386.pkg ```json Ahora importaremos la configuración con el archivo xml que copiamos al servidor con el siguiente comando ```text veeamconfig mode setVbrSettings --cfg Unix.xml ```text Y nos indicará que esta registrando el agente con el servidor de Veeam Backup Y podremos ver el estado del agente en el protection group que creamos anteriormente ## Creación Política de Backup Ahora, en la consola de Veeam Backup \u0026amp; Replication realizaremos la configuración de una política de respaldo para que sea aplicada al Veeam Agent for Solaris que instalamos anteriormente. Solo debemos ir a \u0026#34;Backup Job\u0026#34; y seleccionar \u0026#34;Unix Computer\u0026#34; Al ser Unix, en esta versión de VBR, la opcion seleccionada por defecto sera \u0026#34;Managed by Agent\u0026#34;, por tanto, solo debes hacer click en Next y pasar a configurar el nombre de nuestra politica Luego de agregar el nombre a la política debemos seleccionar el grupo de protección o el servidor que vamos a configurar Y nos mostrará el servidor (o protection group) seleccionado, luego next En este paso debemos seleccionar como vamos a respaldar el servidor, nos aparecen dos opciones: Las dos opciones son: - Entire Machine - Respaldara toda el servidores, excluyendo los puntos de montajes de red - Custom Scope - Respaldara las rutas que se ingresen en la política de respaldo Luego de definir se se respaldara toda el sistema operativo o solo unas rutas del servidor (en mi caso seleccione todo el servidor) nos solicitara indicar cual sera el repositorio de nuestros respaldos, seleccionamos \u0026#34;Veeam backup repository\u0026#34;: Y luego ingresaremos el a dirección de nuestro Veeam Backup Server: Seleccionaremos el repositorio donde alojaremos el respaldo y la cantidad de puntos de restauración Luego revisaremos si utilizaremos Scripts o Indexacion de archivos Y si es necesario seleccionar \u0026#34;enable Application-aware processing\u0026#34; para utilizar scripts donde la configuración es sencilla Para luego pasar al agendamiento de la ejecución del respaldo Por ultimo veremos un resumen de la configuración Y veremos la política en funcionamiento Por ultimo, como recomendación, solo por la primera vez, podemos forzar la primera sincronización entre Veeam Agent for Solaris como se indica en el readme.txt con el comando desde el servidor Solaris ```text veeamconfig mode syncnow Luego en la ejecución del respaldo podremos ver las estadísticas:\nY por ultimo la recuperación de cualquier archivo.\nPosts relacionados # Veeam Agent Linux - Oracle Linux / Exadata Veeam Oracle RMAN Plugin Veeam Plugin SAP HANA ","date":"6 de octubre de 2021","externalUrl":null,"permalink":"/es/posts/veeam-agent-para-solaris-y-veeam-11a/","section":"Blog","summary":"En este post revisaremos una de las funcionalidades nuevas en la ultima versión de Veeam Backup \u0026 Replication 11a que se ha lanzado recientemente e incluye la gestión desde la consola de Veeam Backup \u0026 Replication para los agentes Unix, Veeam Agent for Solaris y Veeam Agent for AIX","title":"Veeam Agent para Solaris y Veeam 11a","type":"posts"},{"content":"","date":"6 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/veeam-agent-for-solaris/","section":"Etiquetas","summary":"","title":"Veeam-Agent-for-Solaris","type":"tags"},{"content":"","date":"6 de octubre de 2021","externalUrl":null,"permalink":"/es/tags/veeam-oracle-solaris/","section":"Etiquetas","summary":"","title":"Veeam-Oracle-Solaris","type":"tags"},{"content":"","date":"2 de agosto de 2021","externalUrl":null,"permalink":"/es/tags/como-instalar-hardened-repository/","section":"Etiquetas","summary":"","title":"Como-Instalar-Hardened-Repository","type":"tags"},{"content":"","date":"2 de agosto de 2021","externalUrl":null,"permalink":"/es/tags/respaldo-inmutables-rhel/","section":"Etiquetas","summary":"","title":"Respaldo-Inmutables-Rhel","type":"tags"},{"content":"","date":"2 de agosto de 2021","externalUrl":null,"permalink":"/es/tags/respaldos-inmutables/","section":"Etiquetas","summary":"","title":"Respaldos-Inmutables","type":"tags"},{"content":" En este post, revisaremos la instalación de un repositorio Inmutable de Veeam con Red Hat Enterprise Linux, anteriormente revisamos una aplicación para Ubuntu llamada VeeamHubRepo, el cual nos permite fácilmente configurar un repositorio inmutable en Ubuntu Linux. Ahora revisaremos como realizar la configuración en Red Hat Enterprise Linux, con un pequeño script para la configuración del repositorio de manera automática y de fácil uso.\nIntroducción # Como vimos anteriormente en otro post, tenemos la guía paso a paso de la configuración del repositorio inmutable de Veeam para Ubuntu con un utilitario, puedes revisarlo en:\n/veeam-hardened-immutable-repository/\nAhora si lo que buscas es una forma fácil de configurar pero en Red Hat Enterprise Linux para proveer la inmutabilidad de respaldos en tu ambiente local, este post es para ti.\nBuenas Prácticas Veeam Immutable Repository # A continuación revisaremos alguna buenas practicas para este tipo de repositorio que nos permite almacenar nuestros respaldos de forma inmutable sobre Linux:\nNo agregar mas roles de Veeam u otros servicios, es decir, este repositorio debe ser únicamente para respaldos inmutables De preferencia que sea un Servidor Físico con discos locale s (JBOD) Bloquear o deshabilitar cualquier aplicación o servicio de administración remota, es decir, SSH (después de configurar el repositorio), ILO, IDRAC, etc. Por que no se recomienda agregar mas roles de veeam o otros servicios de Linux?, como por ejemplo nginx, la respuesta es simple, la idea es mantener lo mas aislado posible tratando de bajar el riesgo en caso de alguna vulnerabilidad o acceso no autorizado al servidor. Ya que como sabemos, últimamente, tenemos múltiples vulnerabilidades 0day que afectan a servicios y sistemas operativos Linux.\nPor que la preferencia un Servidor Físico con discos locales?. Si es una maquina virtual y en caso de ataque lamentablemente se comprometió la seguridad del ambiente virtual, por supuesto el o los atacantes tendrán la posibilidad, inclusive, de eliminar la maquina virtual con todo su contenido o cifrar el ambiente virtual completo. Con respecto a la recomendación de discos locales, apunta exclusivamente a evitar que en el caso de que se haya comprometido la seguridad del almacenamiento o Storage no sea posible eliminar los datos que se almacenan en el repositorio.\nY por ultimo, bloquear o deshabilitar cualquier tipo de acceso de administración remota, para que en caso de el compromiso de credenciales de administración centralizadas o vulnerabilidades en los sistemas de administración remota no sea posible conectarse al sistema operativo.\nLo único que debe tener conexión es Veeam Backup \u0026amp; Replication para enviar Respaldos Inmutables al servidor.\nConfigurar Red Hat Enterprise Linux como Veeam Immutable Repository # En este caso realice la instalación de RHEL 8.3 como servidor con la opción mínima o por defecto sin interfaz gráfica. Y nos conectamos vía SSH con root:\nSi es un servidor físico que ya tiene los discos instalados, procederemos a realizar la ejecución de un script que lo puedes descargar desde:\nhttps://github.com/mescobarcl/rhelimmutable\nSeleccionamos el archivo \u0026ldquo;rhelimm.sh\u0026rdquo; para ver el contenido y lo copiamos:\nLuego de copiar el contenido del archivo, volveremos a la sesión SSH que tenemos abierta. Crearemos un archivo nuevo con el editor \u0026ldquo;vi\u0026rdquo;, por tanto en la sesión de ssh ejecutaremos:\nvi rhelimm.sh ```bash Presionamos \u0026#34;i\u0026#34; para permitir ingresar texto o pegar texto en el archivo: Y salimos del archivo presionando \u0026#34;ESC :\u0026#34; ingresamos \u0026#34;wq!\u0026#34; presionamos enter y volveremos a la linea de comandos Ahora asignaremos permisos de ejecución al archivo con el siguiente comando: ```bash chmod +x rhelimm.sh ```json Y ahora ejecutaremos el script con el comando: ```text ./rhelimm.sh Y presionamos \u0026ldquo;Enter\u0026rdquo; para la ejecución del script que nos solicitará información.\nEjecución Script # Ahora ya hemos ejecutado el script con el paso anterior, lo primero que realiza es un scan de discos nuevos existentes en el servidor. Luego nos lista los discos que encontró para consultarnos si deseamos utilizar solo un disco o varios que existen en el servidor.\nEn este caso para la demostración agregue 4 discos de 50 TB, cabe señalar, que es posible utilizar múltiples discos o solo uno, dependiendo de tu configuración de hardware. por tanto el script nos solicitara que ingresemos los discos en formato \u0026ldquo;/dev/sdb\u0026rdquo; y si utilizaras múltiples discos solo agrega un espacio después de cada disco al ingresarlo:\nComo se visualiza en la imagen anterior, aparecen los discos \u0026quot; /dev/sdb /dev/sdc /dev/sdd /dev/sde\u0026quot;. Los ingreso en el formato deseado y presiono \u0026ldquo;Enter\u0026rdquo; para la ejecucion:\nAl ingresar los discos se crea los volúmenes físicos, el grupo de volumen, el grupo lógico para administrar vía LVM y por ultimo se formatea con XFS el volumen lógico \u0026ldquo;repoveeam\u0026rdquo;, en el formateo se incluye la habilitación de \u0026ldquo;Reflink\u0026rdquo; para el soporte de \u0026ldquo;Fast Clone\u0026rdquo; en este tipo de repositorio.\nLuego del formateo el script nos solicita la contraseña o password para el usuario de conexión, el script crea un usuario de nombre \u0026quot; repouser\u0026quot;, ingresamos la contraseña:\nConfiguración Repositorio Immutable Veeam Backup \u0026amp; Replication # Y ahora el script nos indica que debemos agregar el nuevo repositorio en Veeam Backup \u0026amp; Replication con las credenciales de \u0026quot; repouser\u0026quot; nos conectamos a VBR y agregamos el servidor RHEL dentro de \u0026ldquo;Managed Servers\u0026rdquo;, seleccionaremos \u0026ldquo;Linux Server\u0026rdquo; para ingresar la dirección IP o dns del servidor:\nDespués de hacer clic en \u0026ldquo;Next\u0026rdquo; nos solicitara como será la autenticación con el nuevo servidor RHEL:\nY seleccionaremos \u0026ldquo;Single-use credentials for hardened repository\u0026hellip;.\u0026rdquo; para ingresar las credenciales, utilizaremos el usuario creado por el script \u0026quot; repouser\u0026quot; con sui respectiva contraseña que se ingresó en los pasos del script y también muy importante, seleccionaremos \u0026quot; Elevate account privileges automatically\u0026quot; y \u0026quot; Use su if sudo fails\u0026quot; e ingresamos la contraseña de \u0026ldquo;root\u0026rdquo; presionamos \u0026ldquo;OK\u0026rdquo; y luego \u0026ldquo;Next\u0026rdquo;:\nLos usuarios y contraseñas que estamos ingresando solo serán usados en esta conexión, después las credenciales no quedan almacenadas en la base de datos de Veeam Backup \u0026amp; Replication. Ahora seleccionamos \u0026ldquo;YES\u0026rdquo;\nY podremos ver la instalación del componente necesario para Veeam Backup \u0026amp; Replication:\nSeleccionamos \u0026ldquo;Apply\u0026rdquo; y veremos la instalación finalizada:\nClic en \u0026ldquo;Finish\u0026rdquo; y volveremos a la sesión de SSH. El script estaba esperando la instalación del componente de Veeam necesario chequeando si aparece el proceso para luego preguntarnos si deseamos deshabilitar SSH por completo:\nIngresamos 1 para deshabilitar y detener el servicio SSH y luego nos desconectamos con el comando \u0026ldquo;exit\u0026rdquo;. Luego podremos comprobar que no sera posible conectarnos nuevamente vía SSH inclusive luego de un reinicio. Cabe señalar que el script agregar el volumen en \u0026quot; /etc/fstab\u0026quot; para que en caso de reinicio los discos se monten automáticamente.\nAhora volvemos a Veeam Backup \u0026amp; Replication para terminar la configuración del Repositorio Inmutable.\nCreación Veeam Immutable Repository # En la consola de VBR, ingresaremos a \u0026ldquo;Backup Repositories\u0026rdquo;, luego botón derecho del mouse y seleccionamos \u0026ldquo;Add Backup Repository\u0026rdquo;, luego \u0026ldquo;Direct Attached Storage\u0026rdquo;, después \u0026ldquo;Linux\u0026rdquo; para ingresar los datos que nos solicitara Veeam:\nClic en \u0026ldquo;Next\u0026rdquo; y seleccionaremos nuestro nuevo servidor Linux RHEL. donde ademas haremos clic en \u0026ldquo;Populate\u0026rdquo; para ver el disco o punto de montaje para almacenar los respaldos:\nSeleccionamos \u0026ldquo;/repoveeam\u0026rdquo; y hacemos clic en \u0026ldquo;Next\u0026rdquo;\nDonde habilitaremos \u0026ldquo;Use fast cloning on XFS volumes\u0026hellip;\u0026rdquo; y \u0026ldquo;Make recent backup immutable for\u0026rdquo;, aquí puedes dejar por defecto la inmutabilidad de los respaldos por 7 días o ingresar la configuración que sea necesaria en días. Luego \u0026ldquo;Next\u0026rdquo;\nSeleccionaremos el \u0026ldquo;Mount Server\u0026rdquo; luego \u0026ldquo;Next\u0026rdquo;, después \u0026ldquo;Apply\u0026rdquo; para ver el estatus de configuración:\nLuego nos preguntara si deseamos cambiar la ubicación del respaldo de la configuración y seleccionamos \u0026ldquo;No\u0026rdquo;.\nValidación de Configuración # Ahora crearemos un Job de respaldo de alguna maquina virtual y seleccionaremos nuestro nuevo repositorio inmutable:\nY lo ejecutamos, esperamos la finalización:\nY por ultimo intentaremos la eliminación del respaldo desde la consola de Veeam Backup \u0026amp; Replication, donde nos indicará:\nEl respaldo no es posible eliminarlo hasta el día 08-08-2021.\nPosts relacionados # Veeam Hardened (Immutable) Repository Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam Plan de Respuesta ante Incidentes con NIST 800-61, 800-53r5, Mitre ATT\u0026amp;CK y Veeam ¿Que Sistema Operativo es más Seguro? ","date":"2 de agosto de 2021","externalUrl":null,"permalink":"/es/posts/veeam-hardened-repository-rhel/","section":"Blog","summary":"En este post, revisaremos la instalación de un repositorio Inmutable de Veeam con Red Hat Enterprise Linux, anteriormente revisamos una aplicación para Ubuntu llamada VeeamHubRepo, el cual nos permite fácilmente configurar un repositorio inmutable en Ubuntu Linux. Ahora revisaremos como realizar la configuración en Red Hat Enterprise Linux, con un pequeño script para la configuración del repositorio de manera automática y de fácil uso.","title":"Veeam Immutable Repository con Red Hat Enterprise Linux","type":"posts"},{"content":"","date":"2 de agosto de 2021","externalUrl":null,"permalink":"/es/tags/veeam-hardened-repository/","section":"Etiquetas","summary":"","title":"Veeam-Hardened-Repository","type":"tags"},{"content":"","date":"2 de agosto de 2021","externalUrl":null,"permalink":"/es/tags/veeam-immutable-repository/","section":"Etiquetas","summary":"","title":"Veeam-Immutable-Repository","type":"tags"},{"content":"","date":"1 agosto 2021","externalUrl":null,"permalink":"/en/tags/immutable-backup-rhel/","section":"Tags","summary":"","title":"Immutable-Backup-Rhel","type":"tags"},{"content":"","date":"1 agosto 2021","externalUrl":null,"permalink":"/en/tags/immutable-backups/","section":"Tags","summary":"","title":"Immutable-Backups","type":"tags"},{"content":"","date":"28 de junio de 2021","externalUrl":null,"permalink":"/es/tags/best-practices-oracle/","section":"Etiquetas","summary":"","title":"Best-Practices-Oracle","type":"tags"},{"content":" En este post revisaremos las buenas practicas al realizar la instalación, configuración y administración de Veeam Plugin para Oracle RMAN, basado en la experiencia de múltiples instalaciones y revisiones en distintas empresas de variados tamaños. Incluyendo arquitecturas simples, como también, arquitecturas complejas en alta disponibilidad con Oracle RAC en distintas plataformas x86, SPARC, Power. El objetivo de este post es intentar mantener un estándar de configuración y tareas a realizar para mantener un ambiente ideal para la protección de datos de Oracle. Ademas este post incluye una guía para actualizar a la nueva versión de archivos de respaldos que genera el Plugin en su ultimo release.\nIntroducción # Este post se realiza en base a la experiencia del funcionamiento en múltiples usuarios de Latinoamérica que poseen la solución de base de datos Oracle configurada en alta disponibilidad a través de Oracle RAC. Donde se revisaron distintos tipos de arquitecturas de Veeam Backup \u0026amp; Replication con el uso de Veeam Plugin para Oracle RMAN. El post busca generar una revisión base de los requerimientos, configuraciones y conocer el funcionamiento de Veeam Plugin para Oracle RMAN para ambientes de Oracle RAC con el objetivo de lograr una operación correcta y de acuerdo con las configuraciones necesarias para su ejecución.\nEste documento aplica para la versión de Veeam Backup \u0026amp; Replication v11 como también para Veeam Plugin para Oracle RMAN v11, no obstante, varias de las recomendaciones que se describen en este documento aplican para una versión anterior (v10).\nBuenas Practicas Veeam Plugin para Oracle RMAN # Una de las soluciones de bases de datos más utilizadas a nivel empresarial es Oracle, donde podremos encontrar distintos tipos de instalaciones para lograr alta disponibilidad, la mayor parte de las veces nos encontramos con Oracle Real Application Cluster (RAC), donde se almacenan y ejecutan las bases de datos en alta disponibilidad más importantes, si es que no, el core del negocio de quienes utilizan Oracle.\nAl ser una solución tan importante para las empresas, por supuesto, Veeam desarrolló una solución para la integración entre Oracle y Veeam, para ser más especifico, con Oracle Recovery Manager (RMAN), lo cual permite a los administradores de bases de datos seguir con sus protocolos de protección de datos a través de RMAN, recordemos que RMAN es la solución nativa de Oracle para la realización de respaldos de las bases de datos de Oracle, pero en este caso, utilizaremos Veeam Plugin para Oracle RMAN, para tener la posibilidad de guardar los respaldos en los repositorios de Veeam Backup \u0026amp; Replication.\nRecordemos que Veeam Plugin para Oracle técnicamente, es una librería para Oracle RMAN del tipo SBT, lo que nos permite proveer el espacio de los repositorios de Veeam Backup \u0026amp; Replication para Oracle RMAN con el objetivo de guardar los respaldos realizados nativamente desde RMAN.\nUna de las grandes ventajas de Veeam Plugin para Oracle RMAN es que nos permite realizar la recuperación de las bases de datos de Oracle ya sea vía línea de comandos o a través de Veeam Explorers, lo cual facilita considerablemente la recuperación en caso de desastre. Además, también existe una integración con Oracle cuando son máquinas virtuales realizando el respaldo vía imagen incluyendo el soporte para Oracle Automatic Storage Management (ASM), donde también incluye el respaldo automatizado de los Archive Logs para una recuperación granular y por supuesto incluyendo la realización de recuperación instantánea de bases de datos Oracle, para más información ingresa en el siguiente enlace:\nhttps://helpcenter.veeam.com/docs/backup/vsphere/oracle_backup.html?ver=110\nComo sabemos Veeam Backup \u0026amp; Replication mantiene distintos Veeam Explorers, como, por ejemplo, Veeam Explorer para Active Directory, Veeam Explorer para Exchange, Veeam Explorer para Sharepoint, Veeam Explorer para SQL Server, Veeam Explorer para OneDrive (Veeam Office 365), Veeam Explorer para Microsoft Teams (Veeam Office 365) y por supuesto Veeam Explorer para Oracle. Para más información ingresa en el siguiente enlace:\nhttps://helpcenter.veeam.com/docs/backup/explorers/explorers_introduction.html?ver=110\nPor esto es conveniente realizar la integración entre Veeam y Oracle a través del Plugin de Veeam para Oracle, en este post, hablaremos exclusivamente de algunas buenas prácticas para la utilización de Veeam Plugin para Oracle RMAN, de acuerdo con la experiencia directamente en distintas empresas.\nInstalación # La principal buena práctica para la instalación es utilizar la arquitectura que aplique para el sistema operativo y Oracle donde estemos instalando Veeam Plugin Para Oracle RMAN, siempre la recomendación es instalar Veeam Plugin para Oracle RMAN en todos los nodos de Oracle RAC, recordemos que Veeam Backup \u0026amp; Replication posee las siguientes versiones del Plugin:\nVeeam Plugin para Oracle RMAN sobre AIX ppc64 Veeam Plugin para Oracle RMAN sobre Linux x86 y x64 Veeam Plugin para Oracle RMAN sobre Solaris x86 y SPARC Veeam Plugin para Oracle RMAN sobre Windows \\\\ https://helpcenter.veeam.com/docs/backup/plugins/rman_plugin.html?ver=110 **\nEn la mayoría de los casos encontramos Oracle RAC sobre Linux, por tanto, hablaremos de buenas prácticas asociadas a este tipo de ambientes lo que no quiere decir que no aplique para las demás versiones y/o sistemas operativos.\nDe acuerdo con la versión que se instale la primera buena práctica es:\nInstalación con Usuario “root” Configuración con el usuario dueño de la instalación de Oracle, por lo general es el usuario “oracle” Y aquí es donde es muy importante que el usuario dueño de la instalación de Oracle mantenga los permisos necesarios ya sea a nivel de archivos, carpetas y pertenencias a grupos de la instalación de Oracle, incluyendo Oracle Grid, como se indica en:\nhttps://helpcenter.veeam.com/docs/backup/plugins/rman_plugin_permissions.html?ver=110\nInclusive, en el blog existe un post relacionado a los permisos o al error que aparece en al configuración cuando no tienen los permisos adecuados:\n/solucion-veeam-oracle-permission-denied/\nOracle Temp Tablespace # Una muy buena práctica siempre en las bases de datos Oracle es mantener espacio disponible en tablas temporales o como es muy conocida Temp Tablespace para las operaciones normales del funcionamiento de las bases de datos como también para almacenar datos temporales de las instancias que actualmente se mantengan activas.\n¿Cuál es la interacción entre tablas temporales con el respaldo de RMAN vía Veeam Plugin para Oracle RMAN? en esta tabla temporal Oracle RMAN utiliza el espacio para almacenar datos estadísticos de las sesiones de respaldo como también datos de utilización de recursos para tomar las decisiones de ejecución de respaldos en los servidores que mantengan recursos libres. Por ejemplo, Oracle RMAN utiliza esta tabla temporal para almacenar metadatos sobre los objetos recuperados para el orden de éstos.\nTambién, Veeam Plugin para Oracle RMAN, realiza consultas de estadísticas de los procesos de Oracle RMAN, es por ello, que se debe validar que siempre exista espacio disponible en la tabla temporal para que no ocurran errores inesperados o durante el tiempo de ejecución en la plataforma.\nConfiguración # Antes de alguna configuración en Oracle RAC, primero debemos dejar preparado un repositorio dedicado para los respaldos de Oracle RMAN a través de Veeam Plugin para Oracle RMAN, donde después de crear el repositorio utilizando REFS o XFS, ya sea Simple o Scale-Out (SOBR), se debe agregar al usuario que tendrá permisos para utilizar el repositorio en conjunto con el Plugin de Veeam, para ello debemos agregarlo en “Access Permissions”\nPor supuesto al configurar nuestros repositorios para recibir los respaldos de Oracle RMAN necesitaremos mantener una correcta configuración de las tareas concurrentes para que no existan cuellos de botella o encolamientos de procesos para escribir los datos en el repositorio, de hecho, más adelante revisaremos los requerimientos para los canales Oracle RMAN y tareas de Veeam Backup \u0026amp; Replication.Al realizar esto ya podremos pasar a la configuración del Plugin.\nComo vimos en el punto anterior de Instalación, la configuración debe realizarse con el usuario dueño de la instalación de Oracle, generalmente se utiliza el usuario “oracle”, donde se debe ejecutar el comando que se muestra al finalizar la instalación del Plugin “ OracleRMANConfigTool \u0026ndash;wizard”:\nAl realizar la ejecución del comando, Veeam Plugin para Oracle RMAN examina y/o analiza toda la configuración de las instancias existentes en la instalación de Oracle, revisará los archivos de configuración de Oracle que mantienen información de las instancias y a su vez la ejecución de algunos comandos para validar la identificación de las instancias de bases de datos, como también query\u0026rsquo;s o consultas a las instancias para la identificación de ASM, validación de CONTROLFILE, SPFILE, etc. Algunos de los archivos revisados y comandos son:\n/etc/oratab /u01/app/oraInventory/ContentsXML/inventory.xml /u01/app/oracle/product/[version]/db_1/oraInst.loc srvctl status home srvctl config database -d [Nombre DB] srvctl status instance -d [Nombre DB] -n [Servidor Oracle] Por lo anterior, los permisos y pertenencias a los grupos de instalación de Oracle que utiliza el usuario dueño de la aplicación (generalmente “oracle”) son muy importantes para la detección y configuración del entorno para Veeam Plugin para Oracle RMAN.\nVeeam Plugin para Oracle RMAN nos solicitará cierta información que debemos ingresar como por ejemplo la dirección del servidor de Veeam, el puerto por defecto y las credenciales de usuario que agregamos en la configuración de “Access Permissions” para el acceso al repositorio de respaldo. Ahora visualizaremos el repositorio que tenemos configurado, lo seleccionaremos con el numero que antecede al nombre del repositorio.\nEn esta parte es posible realizar la configuración hacia múltiples repositorios de respaldos de Veeam Backup \u0026amp; Replication, solo se debe agregar los repositorios por número conteniendo un espacio.\nY en la siguiente pregunta, “ Enter the number of data streams (From 1 to 254) to run in parallel for each repository (RMAN DEVICE PARALLELISM value). Channel count per device [4]:” es muy importante saber cuántos canales o streams utilizaremos al realizar el respaldo. Para esto debemos considerar lo siguiente:\n1 Core de CPU y 200 MB de RAM por cada canal usado en el servidor de Oracle o nodo de RAC 1 Core de CPU y 1 GB de RAM por cada 5 canales usados para el repositorio de Veeam Backup Por tanto, cuando configuremos esta opción debemos tener en cuenta los requerimientos de hardware ya sea para los servidores de Oracle como también para el repositorio de Veeam Backup \u0026amp; Replication, de lo contrario podríamos tener algún tipo de cuello de botella.\nEste punto por lo general siempre trae preguntas, como, por ejemplo, ¿Cómo funciona? Sabemos que Oracle RMAN puede utilizar múltiples canales ( con un máximo de 255 canales y cada canal puede leer 64 archivos en paralelo) con el objetivo de mejorar el rendimiento y paralelismo para la realización del respaldo nativamente, pero en este caso, con Veeam Plugin para Oracle RMAN lo que busca es que la configuración de la cantidad de canales utilizados por defecto en cada respaldo sea de forma global, por supuesto, siempre este tipo de configuraciones globales pueden ser sustituidas en la tarea o script de respaldo que mantienen los administradores de las bases de datos y/o Oracle.\nCabe señalar, como indicamos anteriormente, que Veeam Plugin para Oracle RMAN debe ser instalado en cada uno de los servidores que componen el RAC de Oracle, ya que Oracle RMAN puede utilizar cualquier nodo disponible con recursos para la realización de sus tareas y aquí es donde revisaremos una tabla muy importante de Oracle.\nCuantos canales se deben utilizar, dependiendo de los recursos, con 4 canales es un buen inicio, por supuesto la cantidad de canales siempre va a ser limitada por la cantidad de recursos que existan en el clúster de Oracle, en general siempre los usuarios utilizan excelentes recursos de hardware para este tipo de soluciones. Siempre es conveniente que existiendo los recursos elevar la cantidad de canales a utilizar para mejorar el rendimiento.\nY ya que hablamos de recursos y canales que utilizara RMAN, por supuesto, es necesario recomendar una red 10gb, ya que a la mayor cantidad de canales usados es mayor la cantidad de ancho de banda que utilizara Oracle RMAN y Veeam Plugin para Oracle RMAN para la transferencia de los respaldos hacia el repositorio de Veeam Backup \u0026amp; Replication.\nY, por último, si se desea asignar canales manualmente se debe revisar el siguiente enlace:\nhttps://helpcenter.veeam.com/docs/backup/plugins/rman_allocation_backup.html?ver=110\nLuego de entender e ingresar los canales a utilizar por Oracle RMAN a través de Veeam Plugin para Oracle RMAN, la solución nos hace la siguiente pregunta, ¿Do you want to use Veeam compression? (y/N). Aquí nuevamente es un tema de recursos como también de decisión si es necesario o no habilitar la compresión de Veeam Backup \u0026amp; Replication, en el siguiente enlace está el detalle de la compresión que realiza Veeam Backup \u0026amp; Replication y los recursos que son necesarios\nhttps://helpcenter.veeam.com/docs/backup/vsphere/compression_deduplication.html?ver=110\nPero como estamos hablando de buenas prácticas de acuerdo con la experiencia de los usuarios, la recomendación inicial es No mantener habilitados las compresiones tanto de Oracle como de Veeam ya que exigirá recursos y afectará el rendimiento completo de los procesos de respaldo.\nY como recomendación general inicialmente no utilizar la compresión de Veeam a menos que existan recursos sobrantes para la ejecución de la compresión de los datos de Oracle.\nAl seleccionar que no realizaremos la compresión, Veeam Plugin para Oracle RMAN nos indicara cuales son las instancias que detectó en el sistema operativo y por supuesto la configuración que se aplicará a Oracle RMAN de forma global.\nLuego existen las siguientes 3 opciones que nos indican si aplicaremos los cambios a Oracle RMAN, Exportamos la configuración para aplicarla manualmente o, por último, no aplicar ningún cambio.\nOperación y Ejecución de Respaldos # Generalmente para la operación y ejecución de los respaldos con Oracle RMAN siempre utilizan scripts ya desarrollados por los administradores de Bases de Datos con la configuración deseada de la retención como también de parámetros adicionales de acuerdo con las exigencias del negocio.\nEn este punto una de las recomendaciones más importantes para la protección de las instancias es que los scripts de respaldo sean lo más simple posible y utilicen la configuración global de Oracle RMAN que se aplica al configurar Veeam Plugin para Oracle RMAN, sin la necesidad de declarar la librería SBT o los canales que utilizaran en los scripts de respaldo.\nAsí como también aplica para el respaldo de Archive Logs donde se recomienda que la ejecución utilice las variables globales de RMAN.\nEsto no quiere decir que no se pueda sustituir la configuración desde el script, solo que, de acuerdo con las configuraciones que hemos revisado, ha sido la mejor opción para una estandarización de scripts y mantención de éstos.\nOtro tema muy importante, siempre se debe finalizar la ejecución con la salida del script utilizando el comando EXIT, ya que en el caso de que Oracle RMAN no pudiese liberar la sesión, ésta quedara tomada y se mantendrá en ejecución el proceso hasta que se cancele el proceso de RMAN manualmente. En Veeam Backup \u0026amp; Replication, se verá la ventana de estadísticas siempre funcionando a la espera de la finalización de la sesión de Oracle RMAN.\nArchivos adicionales para Respaldar # Aparte de los archivos de bases de datos y archive logs que se protegerán con Oracle RMAN a través de Veeam Plugin para Oracle RMAN, siempre se deben respaldar archivos de configuración de Oracle, comúnmente las carpetas raíz ($ORACLE_HOME) de los usuarios Oracle y Grid.\nAdemás, es necesario respaldar los archivos de configuración de Veeam Plugin para Oracle RMAN que se generan en el sistema operativo.\nPara respaldar estas carpetas es posible utilizar Veeam Agent para Linux con la configuración de respaldos a nivel de archivos sin snapshots:\nhttps://helpcenter.veeam.com/docs/agentforlinux/userguide/file_backup_snapshotless.html?ver=50\nGeneralmente las rutas con todo su contenido recursivo a respaldar son:\n/etc/oratab /u01/ /opt/veeam Por supuesto si las rutas de instalación son distintas, es necesario agregarlas.\nY cualquier otra ruta que sea necesaria para los administradores de bases de datos y/o para una recuperación ante desastres.\nInteroperabilidad y Actualizaciones # En los usuarios que ya tienen Veeam Plugin para Oracle RMAN desde la versión de Veeam Backup \u0026amp; Replication 9.5 donde se han realizados las actualizaciones hasta la última versión de Veeam Backup \u0026amp; Replication (V11 a la fecha de este documento), siempre se consideró validar la interoperabilidad de las versiones, las cuales son:\nVeeam Plug-in para Oracle RMAN 9.5 Update 4 soporta integración con Veeam Backup \u0026amp; Replication versión 9.5 Update 4, 9.5 Update 4a, y 9.5 Update 4b, 10. Veeam Plug-in para Oracle RMAN 10 (10.0.1.4854) soporta integración solo con Veeam Backup \u0026amp; Replication versión 10. Veeam Plug-in para Oracle RMAN 10.0.1.4854 (10a Cumulative Patch 20201202) soporta integración con Veeam Backup \u0026amp; Replication versión 10, 11. Veeam Plug-in para Oracle RMAN 11 soporta integración solo con Veeam Backup \u0026amp; Replication versión 11. Es importante señalar esta interoperabilidad ya que muchas veces solo se actualizan las versiones de Veeam Backup \u0026amp; Replication y no se realiza la actualización de Veeam Plugin para Oracle RMAN lo que induce a errores inesperados . Por tanto, siempre se recomienda realizar la actualización de todos los componentes que involucran a la implementación de Veeam Backup \u0026amp; Replication.\nA partir de la versión 11 de Veeam Plugin para Oracle RMAN utiliza un nuevo formato de los archivos de respaldos, en vez de usar solo un archivo de metadatos para todos los archivos de respaldos que se utilizaba en las versiones anteriores, desde ahora en la versión 11, existe un archivo de metadatos separados para todos los archivos de respaldos. Lo que permite optimizar la productividad de las operaciones de respaldo y recuperación\nPara actualizar Veeam Plugin para Oracle RMAN es muy fácil, dependiendo del sistema operativo, se procede a la descarga de la nueva versión del paquete de instalación como se explica en la siguiente documentación\nhttps://helpcenter.veeam.com/docs/backup/plugins/update_rman_plugin.html?ver=110\nYa que en v11 existen nuevos archivos de respaldo y metadatos es necesario realizar la actualización de éstos, si se mantienen respaldos realizados con versiones anteriores de Veeam Plugin para Oracle RMAN, por ejemplo, en la siguiente imagen observamos un respaldo con la versión 10 de Veeam Plugin para Oracle RMAN, donde nos indica:\n“Backup metadata is not up to date. Please upgrade the backup “\nEl mensaje indica que los metadatos deben ser actualizados, para realizar esta acción recomendada, primero que todo, debemos tener actualizado Veeam Backup \u0026amp; Replication en la última V11 y por supuesto Veeam Plugin para Oracle RMAN en la última V11 y luego se debe ingresar a la consola de Veeam Backup \u0026amp; Replication, luego en el menú de “Backups”, seleccionar “Disk” donde visualizaremos el respaldo de Oracle RMAN y realizamos clic derecho sobre él:\nAquí veremos una nueva función “Upgrade” que aparecerá siempre en los respaldos con versiones anteriores a v11, lo que nos permitirá actualizar nuestros archivos de respaldos y metadatos con Veeam Plugin para Oracle RMAN de versiones anteriores. Al hacer clic en ”Upgrade” Veeam Backup \u0026amp; Replication nos indicará que se necesitan las tareas de respaldos deshabilitadas para realizar la acción de actualización\nSolo debemos ingresar a la administración de tareas de Veeam Backup \u0026amp; Replication haciendo clic en “Jobs” y luego en “Backup” para luego identificar la tarea de respaldo de Veeam Plugin para Oracle RMAN y proceder a deshabilitarlo\nAl mantener deshabilitada la tarea de respaldo, volveremos a “Backups” luego “Disk” y seleccionamos nuevamente el respaldo de Oracle RMAN para realizar el “Upgrade” donde nos indicara el mensaje\nConsultando si tenemos todos los componentes actualizados a la ultima versión, es decir Veeam Backup \u0026amp; Replication v11 (en su última actualización), como también Veeam Plugin para Oracle RMAN en su última versión, al seleccionar “Yes” nos mostrará el estado de la operación\nEl tiempo de duración de esta operación dependerá siempre del número de archivos de respaldos de Oracle, el tipo de repositorio y por supuesto la carga de trabajo en el sistema de archivos. Si los archivos están alojados en algún dispositivo de Deduplicación, posiblemente tome más tiempo de acuerdo con las operaciones del mismo dispositivo que debe rehidratar los datos para que Veeam Backup \u0026amp; Replication actualice los archivos y metadatos.\nArchivos de Configuración y Logs # En ciertos casos siempre es recomendable saber la ubicación de los distintos archivos de configuración, en caso de que sea necesario a editar manualmente, soporte indique algún cambio y por supuesto saber la ubicación de los archivos de logs en caso de realizar alguna revisión por un mal comportamiento de la solución o tomar los archivos para actualizar un caso de soporte.\nLa ubicación por defecto de los archivos de configuración de Veeam Plugin para Oracle RMAN\nLinux, Solaris, AIX en /opt/veeam/VeeamPluginforOracleRMAN Windows C:\\Program Files\\Veeam\\VeeamPluginforOracleRMAN Estos archivos de configuración deben ser editados de acuerdo con las directrices de soporte técnico de Veeam.\nY para las ocasiones que sean necesario revisar archivos de logs o enviar logs para soporte la ruta de estos archivos\nLinux, Solaris, AIX /tmp/veeam_plugin_logs/ Windows %ProgramData%\\Veeam\\Backup\\RmanPluginLogs O utilizar el KB\nhttps://www.veeam.com/kb2871\nConsideraciones Generales # Una recomendación general, es que siempre los sistemas operativos involucrados en la protección de las bases de datos Oracle deben estar actualizados, siempre y cuando la operación lo permita, para el caso de los roles de Veeam Backup \u0026amp; Replication, específicamente los repositorios, además contar con las actualizaciones de los drivers de los dispositivos de red, ya que en ciertos al realizar la actualización ya sea del sistema operativo y también de los drivers de las interfaces de red, el respaldo de los datos mejoro considerablemente.\nPor otra parte siempre se recomienda utilizar que todos los servicios, servidores y sistemas involucrados posean direcciones DNS FQDN para que la configuración sea lo mas completa posible.\nEso es todo, trate de realizarlo lo más completo y detalaldo posible, como siempre, son bienvenidas las ideas o comentarios adicionales.\nPosts relacionados # Veeam Oracle RMAN Plugin Veeam Explorer Oracle RMAN Solución Veeam Oracle Permission Denied Veeam Agent Linux - Oracle Linux / Exadata ","date":"28 de junio de 2021","externalUrl":null,"permalink":"/es/posts/buenas-practicas-veeam-plugin-oracle-rman/","section":"Blog","summary":"En este post revisaremos las buenas practicas al realizar la instalación, configuración y administración de Veeam Plugin para Oracle RMAN, basado en la experiencia de múltiples instalaciones y revisiones en distintas empresas de variados tamaños. Incluyendo arquitecturas simples, como también, arquitecturas complejas en alta disponibilidad con Oracle RAC en distintas plataformas x86, SPARC, Power. El objetivo de este post es intentar mantener un estándar de configuración y tareas a realizar para mantener un ambiente ideal para la protección de datos de Oracle. Ademas este post incluye una guía para actualizar a la nueva versión de archivos de respaldos que genera el Plugin en su ultimo release.","title":"Buenas Prácticas Veeam Plugin Oracle RMAN","type":"posts"},{"content":"","date":"28 de junio de 2021","externalUrl":null,"permalink":"/es/tags/buenas-practicas/","section":"Etiquetas","summary":"","title":"Buenas-Practicas","type":"tags"},{"content":"","date":"28 de junio de 2021","externalUrl":null,"permalink":"/es/tags/buenas-practicas-veeam-oracle-plugin/","section":"Etiquetas","summary":"","title":"Buenas-Practicas-Veeam-Oracle-Plugin","type":"tags"},{"content":"","date":"28 de junio de 2021","externalUrl":null,"permalink":"/es/tags/veeam-oracle/","section":"Etiquetas","summary":"","title":"Veeam-Oracle","type":"tags"},{"content":"","date":"28 de junio de 2021","externalUrl":null,"permalink":"/es/tags/veeam-oracle-best-practices/","section":"Etiquetas","summary":"","title":"Veeam-Oracle-Best-Practices","type":"tags"},{"content":"","date":"28 de junio de 2021","externalUrl":null,"permalink":"/es/tags/veeam-rman/","section":"Etiquetas","summary":"","title":"Veeam-Rman","type":"tags"},{"content":" En esta guía revisaremos como instalar Kasten Multi-Cluster Manager para la gestión y protección de contenedores de múltiples clusters de kubernetes en diferentes ambientes con la administración centralizada de recursos. Por lo general en la mayoría de las empresas que mantienen equipos de desarrollo de aplicaciones existen distintos tipos de ambientes como por ejemplo , Desarrollo, QA y Producción, en otras empresas también manejan ambientes de Pre-Producción, Stagging, UAT, etc. De igual manera todo depende mucho del ciclo de vida del desarrollo como de las arquitecturas de cada empresa, es por esto que con Kasten Multi-Cluster Manager podremos conseguir la protección de múltiples ambientes y/o clusters de kubernetes.\nPasos Iniciales # Como comentaba anteriormente es necesario tener una protección de tus datos independientemente de donde este alojados o el tipo de carga de trabajo, ya que en caso de algún desastre, ataque de malwares u otros motivos es posible perder datos y más aun que hoy en día manejamos los datos en muchos ambientes, esparcidos geográficamente y que necesitan una gestión centralizada de los recursos y también la protección de éstos.\nEs por ello, Kasten by Veeam desarrolló la solución Kasten Multi-Cluster Manager que nos permite gestionar los recursos de respaldo centralizadamente como también la protección de datos basadas en políticas de respaldos para los clusters. Como siempre revisaremos la documentación oficial que encontraremos\nhttps://docs.kasten.io/latest/multicluster/index.html\nAmbientes # Para esta guía tengo dos cluster de kubernetes integrados con vSphere a través de vSphere-CSI, cada uno con 3 nodos Worker y 1 Master, también tengo un ubuntu Linux que utilizo para la administración de kubernetes. Ademas tienen instalado contenedores de mongodb, MySQL y Wordpress para validar el respaldo de los ambientes con aplicaciones, aparte de todos los servicios asociados al cluster.\nDebemos tener instalado en cada cluster de kubernetes o tu distribución de kubernetes, Kasten K10, si aun no lo tienes instalado, puedes seguir la guía que aplica para cualquier versión de kasten k10:\n/veeam-kasten/#Instalacion_de_Kasten\nY una consideración importante es definir cual sera tu Cluster Primario y Secundario(s), en este caso yo definiré mi cluster de nombre \u0026ldquo;produccion\u0026rdquo; como primario y el secundario como \u0026ldquo;desarrollo\u0026rdquo;, esto es clave para la configuración del Multi-Cluster de Kasten.\nKubernetes Contexts # Esta configuración de kubernetes contexts nos permitirá en pocas palabras administrar múltiples clusters de kubernetes centralizadamente y nativamente desde una maquina que contenga los archivos de configuración y/o conexión, comúnmente conocidos como KUBECONFIG, por tanto procederemos a copiarlos a la maquina de administracion\nscp /home/mescobar/.kube/config mescobar@mgmtCLI:/home/mescobar/.kube/produccion scp /home/mescobar/.kube/config mescobar@mgmtCLI:/home/mescobar/.kube/desarrollo ```text En los comandos anteriores estoy copiando el archivo de configuración desde mis servidores **MASTER** donde comúnmente lo encontraras en $HOME/.kube/config o dentro del home del usuario que estas usando en la carpeta oculta .kube hacia mis servidor de administración (mgmtCLI). En el caso que por algún motivo no encuentres el archivo de configuración, puedes copiar el siguiente archivo de la siguiente ruta hacia tu servidor de administración ```bash sudo scp /etc/kubernetes/admin.conf mescobar@mgmtCLI:/home/mescobar/.kube/produccion ```bash Ahora si listamos el directorio podremos ver los distintos archivos de los clusters Y con el siguiente comando revisaremos que archivo de configuración esta cargado ```bash echo $KUBECONFIG kubectl config get-contexts ```json Como se ve en la imagen anterior tengo otro archivo de configuración y esta cargado en el contexto, por tanto vamos a configurar la variable de entorno KUBECONFIG para que cargue los clusters cada vez que ingresemos con nuestro usuario al servidor de administración, por tanto realizaremos lo siguiente ```text cd $HOME nano .bashrc ```text Y nos dirigimos a la ultima linea y agregaremos ```bash export KUBECONFIG=$HOME/.kube/produccion ```json Guardamos el archivo y ejecutamos el siguiente comando para cargar la variable de entorno ```text . .bashrc ```bash Asi con esto podremos validar nuevamente si esta cargado el archivo que necesitamos ```bash echo $KUBECONFIG kubectl config get-contexts ```bash ### Configuración Contexts Como podemos ver en la imagen anterior, el nombre de nuestro cluster esta por defecto \u0026#34;kubernetes-admin@kubernetes\u0026#34; lo cual podría traer confusión para saber cual cluster estamos administrando, es por eso que vamos a cambiar el nombre para que sea mucho mas facil con el siguiente comando: ```bash kubectl config rename-context kubernetes-admin@kubernetes produccion ```json Ahora ya tenemos identificado el cluster y procederemos a agregar el cluster de desarrollo. Como vimos en un punto anterior agregaremos en el archivo .bashrc la ruta del archivo de configuración de desarrollo y ejecutaremos el comando para cargar esa nueva variable (utiliza el nombre de archivo que pertenece a tus clusters) ```bash export KUBECONFIG=$HOME/.kube/produccion:$HOME/.kube/desarrollo ```bash Ejecutamos los comandos para cargar la variable y ver los contexts y nuevamente cambiamos el nombre por defecto para identificar el ambiente de desarrollo ```bash kubectl config rename-context kubernetes-admin@kubernetes desarrollo ```bash Por que realizamos lo anterior? netamente por que cuando se configuran cluster de kubernetes por con configuraciones por defecto, el nombre del cluster siempre será kubernetes-admin@kubernetes, también el nombre del cluster sera kubernetes, el cambio de nombre en el contexto es importante para saber a que cluster nos estaremos conectando. Y por ultimo para cambiar entre clusters o contextos utilizaremos el siguiente comando ```bash kubectl config use-context desarrollo ```bash Como podrás observar en la imagen anterior o en tu sesión, para ver el cambio de contexto se confirma en la columna \u0026#34; **CURRENT**\u0026#34; donde se ve un **\\*** es el cluster que actualmente estas administrando. Ademas como **recomendación** en los **archivos de configuración puedes cambiar el nombre del cluster para asegurarte** aun más sobre que cluster estás usando, de igual manera hay muchísima información en Internet que cubre esta configuración. ## Configuración Kasten Como recordarás, anteriormente definimos nuestros cluster\u0026#39;s primarios y/o secundarios ya que es un requerimiento de Kasten Multi-Cluster que deben tener instalado Kasten k10 y otro requerimiento que debemos cumplir es que la autenticación de los Kasten **k10 instalados en cada uno** de los cluster\u0026#39;s que serán **SECUNDARIOS** deben ser vía token. Por tanto podemos utilizar la autenticación que deseemos en el cluster primario, pero siempre sera obligatoria la autenticación por token en los cluster secundarios. Para mayor información: [https://docs.kasten.io/latest/access/authentication.html#token-authentication](https://docs.kasten.io/latest/access/authentication.html#token-authentication) Ahora en nuestros cluster secundarios configuraremos la autenticación por token para lo cual deben ejecutar el siguiente comando en el contexto de su cluster secundario o directamente en el servidor master del **CLUSTER SECUNDARIO** ```bash helm upgrade k10 kasten/k10 --namespace=kasten-io \\ \u0026gt; --reuse-values \\ \u0026gt; --set externalGateway.create=true \\ \u0026gt; --set auth.tokenAuth.enabled=true ```bash Con el comando anterior **ejecutado en el o los clusters SECUNDARIOS** no aseguramos que se autentiquen vía token. Y el cluster **PRIMARIO** puede utilizar el método de autenticación que sea necesario. En este caso en el cluster **PRIMARIO** utilizaremos autenticación básica, para configurar esto es necesario ejecutar (usuario y contraseña \u0026#34;kasten\u0026#34;): ```bash helm upgrade k10 kasten/k10 --namespace=kasten-io \\ --set auth.basicAuth.enabled=true \\ --set auth.basicAuth.htpasswd=\u0026#39;kasten:$apr1$twc26zga$AA47exHs1a3uNq/4lDKxD.\u0026#39; \\ --set externalGateway.create=true ```bash Y luego para saber la direccion ip que estara usando este acceso con el comando ```bash kubectl get svc gateway-ext --namespace kasten-io -o wide ```bash Y en la columna \u0026#34; **EXTERNAL-IP**\u0026#34; podrás ver la dirección IP asignada por MetalLB y por supuesto lo puedes asociar a un DNS, en mi caso utilizare kasten.24xsiempre.cl y kastendev.24xsiempre.cl para acceder a los clusters. ## Configuración Kasten Multi-Cluster Manager Ahora que tenemos nuestros clusters configurados con los requisitos para Multi-Cluster de Kasten, pasaremos a descargar la solucion en nuestro servidor de administracion o en el servidor que estas usando como MASTER para la gestion de los cluster. Para descargar Kasten Multi-Cluster Manager, lo debes realizar desde la siguiente dirección (A la fecha descargaremos la versión 4.0.3): [https://github.com/kastenhq/external-tools/releases/download/4.0.3/k10multicluster\\_4.0.3\\_linux\\_amd64](https://github.com/kastenhq/external-tools/releases/download/4.0.3/k10multicluster_4.0.3_linux_amd64) Para descargar directo desde la linea de comandos, otorgar permisos de ejecución y mover a directorio ejecutable: ```bash wget https://github.com/kastenhq/external-tools/releases/download/4.0.3/k10multicluster_4.0.3_linux_amd64 chmod +x k10multicluster_4.0.3_linux_amd64 sudo mv k10multicluster_4.0.3_linux_amd64 /usr/local/bin/k10multicluster k10multicluster ```bash Ahora nos aseguraremos que estamos en el contexto del servidor primario que definimos anteriormente con el comando ```bash kubectl config get-contexts ```json Comprobamos el contexto de mi cluster primario, en este caso producción y procedemos a configurar K10 Multi-Cluster Manager. Con el siguiente comando configuraremos el cluster **PRIMARIO** ```text k10multicluster setup-primary \\ --context=produccion \\ --name=produccion ```bash Donde **context** es el nombre del contexto que tenemos en la configuracion de kubernetes y **name** es el nombre que aparecera en la interfaz. Ahora agregaremos el cluster **SECUNDARIO** con el siguiente comando ```bash k10multicluster bootstrap \\ --primary-context=produccion \\ --primary-name=produccion \\ --secondary-context=desarrollo \\ --secondary-name=desarrollo \\ --secondary-cluster-ingress=http://kastendev.24xsiempre.cl/k10/ Luego de los pasos anteriores, posiblemente aparezca un error 503 o 400 en la interfaz de Kasten Multi-Cluster, esto se debe a que posiblemente no posea permisos para la gestión, para ello debemos ingresar en RBAC Entry y agregar el o los usuarios que utilizaremos para gestionar la protección de datos, en mi caso agregue el usuario k10-admin y con esto ya pude ingresar a toda la gestión.\nSi quedan dudas en esta parte solo debes visitar\nhttps://docs.kasten.io/latest/multicluster/access.html#multi-cluster-admins\nhttps://docs.kasten.io/latest/multicluster/user_access.html#configuring-access-for-multi-cluster-users\nY por ultimo necesitamos configurar todas los recursos globales como también políticas globales que se necesiten, para detalle de como realizarlo debes visitar un post que hice anteriormente\n/kasten-k10-multi-cluster/\nConclusiones # Una de las grandes ventajas que no provee esta solución, es la gestión cenrtralizada de recursos para asignar, ya sea por aplicaciones, cluster o de acuerdo a las necesidades de las soluciones que serán protegidas. Es importante señalar que Kasten Multi-Cluster Manager permite agregar cluster de distintas distribuciones de kubernetes, por ejemplo Red Hat OpenShift, Rancher, EKS, AKS o kubernetes, mientras se cumplan los requerimientos necesarios, como por ejemplo instalar Kasten K10 en cada uno de los clusters, nos permitirá tener un acceso único y centralizado para la protección de contenedores.\nPosts relacionados # Kasten K10 Multi-Cluster Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1 Kasten K10 Authentik Como Instalar Kasten K10 en AWS EKS ","date":"9 de junio de 2021","externalUrl":null,"permalink":"/es/posts/instalar-kasten-multi-cluster-manager/","section":"Blog","summary":"En esta guía revisaremos como instalar Kasten Multi-Cluster Manager para la gestión y protección de contenedores de múltiples clusters de kubernetes en diferentes ambientes con la administración centralizada de recursos. Por lo general en la mayoría de las empresas que mantienen equipos de desarrollo de aplicaciones existen distintos tipos de ambientes como por ejemplo , Desarrollo, QA y Producción, en otras empresas también manejan ambientes de Pre-Producción, Stagging, UAT, etc. De igual manera todo depende mucho del ciclo de vida del desarrollo como de las arquitecturas de cada empresa, es por esto que con Kasten Multi-Cluster Manager podremos conseguir la protección de múltiples ambientes y/o clusters de kubernetes.","title":"Instalar Kasten Multi-Cluster Manager","type":"posts"},{"content":"","date":"9 de junio de 2021","externalUrl":null,"permalink":"/es/tags/kasten-openshift/","section":"Etiquetas","summary":"","title":"Kasten-Openshift","type":"tags"},{"content":"","date":"9 de junio de 2021","externalUrl":null,"permalink":"/es/tags/multi-cluster/","section":"Etiquetas","summary":"","title":"Multi-Cluster","type":"tags"},{"content":"","date":"9 de junio de 2021","externalUrl":null,"permalink":"/es/tags/rancher/","section":"Etiquetas","summary":"","title":"Rancher","type":"tags"},{"content":"","date":"9 de junio de 2021","externalUrl":null,"permalink":"/es/tags/red-hat-openshift/","section":"Etiquetas","summary":"","title":"Red-Hat-Openshift","type":"tags"},{"content":"","date":"4 de junio de 2021","externalUrl":null,"permalink":"/es/tags/cluster-kubernetes/","section":"Etiquetas","summary":"","title":"Cluster-Kubernetes","type":"tags"},{"content":"","date":"4 de junio de 2021","externalUrl":null,"permalink":"/es/tags/containerd/","section":"Etiquetas","summary":"","title":"Containerd","type":"tags"},{"content":"","date":"4 de junio de 2021","externalUrl":null,"permalink":"/es/tags/first-class-disk/","section":"Etiquetas","summary":"","title":"First-Class-Disk","type":"tags"},{"content":" En esta guía revisaremos la instalación y configuración de un cluster Kubernetes sobre Ubuntu 20.04 utilizando containerd, calico, realizando la integración vía vSphere CSI (Container Storage Interface) para proveer los volúmenes persistentes para los contenedores que funcionarán en el cluster. Ademas utilizaremos MetalLB como balanceador de carga para acceder a nuestros servicios.\nIntroducción # Si ya estas aquí, es posible que estés iniciando o ya sepas que es Kubernetes (k8\u0026rsquo;s), para que sirve o cual es la función principal. Aun así siempre es bueno revisar la documentación oficial para saber las nuevas versiones, características y soporte de kubernetes, containerd, calico, MetalLB y los drivers CSI, donde en este caso, vamos a utilizar vSphere CSI para aprovechar las bondades de esta integración.\nhttps://kubernetes.io https://containerd.io h ttps://www.projectcalico.org https://metallb.universe.tf/ https://vsphere-csi-driver.sigs.k8s.io/ Entonces para la instalación del cluster vamos a utilizar 4 maquinas virtuales, con la instalación por defecto de la imagen de Ubuntu server 20.04.2. Importante señalar que esto es para una ambiente de laboratorio, aun así si quisieras pasar a producción siempre debe tener al menos 3 nodos master para conseguir la alta disponibilidad necesaria para la gestión de kubernetes.\nServidores # Para esta guia, utilizaremos los siguientes requerimientos y maquinas:\nNombreCPURAMDiscoHW VersionAvanzadasIPmasterprd4vcpu8G30gbVersion 15 o superiordisk.EnableUUID = TRUE40.40.40.206workerprd012vcpu4G30gbVersión 15 o superiordisk.EnableUUID = TRUE40.40.40.204workerprd022vcpu4G30gbVersión 15 o superiordisk.EnableUUID = TRUE40.40.40.203workerprd032vcpu4G30gbVersión 15 o superiordisk.EnableUUID = TRUE40.40.40.202\nPara los nombres siempre utiliza dns o en su defecto agregarlos en la tabla host de cada servidor, para esta guía yo utilizo mi dns interno para la gestión de nombres. Con respecto a la versión del hw virtual, es necesario que debe ser desde la versión 15 que equivale a la versión de vSphere 6.7 U2 o una versión superior, en este caso lo estaremos configurando con la versión de hw 18 ya que tengo instalado vSphere 7U2 y por último muy importante, cada maquina virtual debe ser configurada con el parámetro avanzado disk.EnableUUID ya que son los requerimientos necesarios para utilizar vSphere CSI. Ademas deben tener acceso a internet.\nInstalación Cluster Kubernetes # Validamos en TODOS los servidores se encuentren completamente actualizados despues de la instalacion\nsudo apt update sudo apt -y upgrade \u0026amp;\u0026amp; sudo reboot ```bash Nos conectamos nuevamente vía SSH con nuestros servidores y nos aseguramos que respondan por dns ahora pasaremos a la instalación de algunos pauetes necesarios y la configuracion del repositorio para apt y posterior una actualizacion de los repositorios de apt ```bash sudo apt -y install curl apt-transport-https curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - echo \u0026#34;deb https://apt.kubernetes.io/ kubernetes-xenial main\u0026#34; | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt update ```bash Ahora pasaremos a instalar los paquetes importantes para la configuración y administración de kubernetes, ```bash sudo apt -y install vim git curl wget kubelet kubeadm kubectl containerd sudo apt-mark hold kubelet kubeadm kubectl containerd ```bash sudo apt-mark hold es para que los paquetes no se remuevan o actualicen de versión automáticamente. ## Deshabilitar Swap Como requerimiento para el cluster de kubernetes es necesario deshabilitar swap, por tanto con los siguientes comandos lo realizaremos ```bash sudo swapoff -a sudo nano /etc/fstab ```text Con el primer comando se deshabilita swap y en el segundo comenta la linea en fstab para que al reinicio no se active nuevamente por tanto quedaria asi ## Configuración ContainerD Ahora es necesario configurar algunos módulos necesarios para el funcionamiento de ContainerD ```bash cat \u0026lt;\u0026lt;EOF | sudo tee /etc/modules-load.d/containerd.conf overlay br_netfilter EOF ```text Con el comando anterior estamos generando el archivo containerd.conf en la ruta para que cargue los modulos overlay y br\\_netfilter, luego de eso activaremos los cambios con los siguientes comandos: ```bash sudo modprobe overlay sudo modprobe br_netfilter ```text Y podemos validar la configuracion con el comando ```bash lsmod | grep br_netfilter ```json Ahora de acuerdo a las necesidades de ContainerD realizaremos algunas configuraciones necesarias que involucran parámetros de kernel para el buen funcionamiento ```bash cat \u0026lt;\u0026lt;EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF ```text Y con el siguiente comando aplicamos los cambios ```bash sudo sysctl --system ```bash Por ultimo realizamos la configuracion y final de containerd ```bash sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo systemctl restart containerd ```bash Con el primero comando se genera la carpeta para luego con el segundo comando dejar el archivo de configuracion en la ruta y finalmente reiniciamos los servicios y nos aseguramos que se inicien al booteo. ## Configuración Nodo Master En esta etapa **SOLO** realizaremos los comandos en el nodo **MASTER** para comenzar con la configuración necesaria. Por tanto con el siguiente comando en el nodo master vamos a inicializar kubernetes ```bash sudo kubeadm init ```bash Este comando puede tomar algún tiempo, por tanto alcanzas para ir a preparar un café. Cuando termine la ejecución nos mostrara lo siguiente: Es importante señalar que ahora la aplicacion nos esta solicitado realizar los siguientes pasos: ```bash To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config Alternatively, if you are the root user, you can run: export KUBECONFIG=/etc/kubernetes/admin.conf You should now deploy a pod network to the cluster. Run \u0026#34;kubectl apply -f [podnetwork].yaml\u0026#34; with one of the options listed at: https://kubernetes.io/docs/concepts/cluster-administration/addons/ Then you can join any number of worker nodes by running the following on each as root: kubeadm join 40.40.40.206:6443 --token u31dsc.dbotgztbrid0f6h0 \\ --discovery-token-ca-cert-hash sha256:efecb019f0351590c1a3b30e61a1ac06b65c617b61bfcf63daae2bf7de010540 ```bash La primera parte genera una carpeta oculta en el home del usuario para almacenar el archivo de configuración de kubernetes y con el cual nos podemos conectar y el export es para dejarlo como variable de entorno el archivo de configuracion y sea posible conectarnos fácilmente. Y por ultimo y muy importante es el comando kubeadm join el cual sirve para agregar los nodos worker al master. Para dejar persistente esta configuración debemos realizar lo siguiente: ```text nano .bashrc ```text Y agregamos al final del archivo ```bash export KUBECONFIG=$HOME/.kube/config ```bash Así cada vez que ingresemos al servidor por ssh tendremos configurada la variable de entorno para conectarnos. ## Configuración Nodos Worker En esta etapa los comando se deben ejecutar solo en los **nodos worker** por tanto como vimos anteriormente debemos ejecutar el comando que nos muestra por pantalla que es único por cada cluster en mi caso: ```bash sudo kubeadm join 40.40.40.206:6443 --token u31dsc.dbotgztbrid0f6h0 \\ --discovery-token-ca-cert-hash ```bash Y al ejecutarlo en cada uno de los nodos worker veras el siguiente resultado: ## Revisión Configuración Cluster Ahora volvemos a la sesión de ssh del nodo master o nos reconectamos al nodo master y ejecutamos el siguiente comando ```bash kubectl get nodes -o wide ```bash Con el cual veremos si los nodos workers fueron agregados al cluster y su estado: Como vemos en la imagen anterior, tenemos toda la información del cluster, la única diferencia es que en el estado de los nodos aparece \u0026#34;NotReady\u0026#34;, nos aparece éste estado ya que no hemos configurado la red del cluster kubernetes donde utilizaremos en este caso Project Calico. ## Configuración Red Cluster Calico Para instalar calico en nuestro cluster de kubernetes, solo debemos ejecutar el siguiente comando en **nuestro nodo MASTER** ```bash kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml ```bash Luego, revisamos nuevamente nuestro cluster con el comando para validar el estado ```bash kubectl get nodes -o wide ```bash Y ya tenemos el estado en \u0026#34;Ready\u0026#34;. ## Configuración Balanceador MetalLB Para instalar MetalLB en nuestro cluster de kubernetes, solo debemos ejecutar los siguientes comandos en **nuestro nodo MASTER** ```bash kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.6/manifests/namespace.yaml kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.6/manifests/metallb.yaml ```bash El primer comando generara el namespace de MetalLB y el segundo todos los requerimientos para el funcionamiento Luego generaremos una contraseña random para el cifrados de las comunicaciones ```bash kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey=\u0026#34;$(openssl rand -base64 128)\u0026#34; ```bash Y por ultimo debemos configurar el rango de direcciones IP que va a utilizar MetalLB para asignar y poder acceder a los servicios desde la red. Para ello debemos utilizar la siguiente configuracion ```bash cat \u0026lt;\u0026lt;EOF | kubectl create -f - apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | address-pools: - name: address-pool-1 protocol: layer2 addresses: - 40.40.40.190-40.40.40.200 EOF ```bash Como vemos en el comando anterior, en mi caso estaré usando un rango de 10 direcciones IP de mi red. Si quieres puedes agregar toda la red /24, pero debe asegurarte que las **direcciones IP estén disponibles**. Luego lo Ejecutar en tu servidor **MASTER** ## Configuración vSphere CSI Para iniciar la configuración de vSphere CSI, hay que crear dos archivos con la configuración necesaria para la conexión hacia vCenter: csi-vsphere.conf ```ini [Global] cluster-id = \u0026#34;kubernetes\u0026#34; #[NetPermissions \u0026#34;A\u0026#34;] #ips = \u0026#34;*\u0026#34; #permissions = \u0026#34;READ_WRITE\u0026#34; #rootsquash = false #[NetPermissions \u0026#34;B\u0026#34;] #ips = \u0026#34;10.20.20.0/24\u0026#34; #permissions = \u0026#34;READ_ONLY\u0026#34; #rootsquash = true [VirtualCenter \u0026#34;vcenter.24xsiempre.cl\u0026#34;] insecure-flag = \u0026#34;true\u0026#34; user = \u0026#34;administrator@vsphere.local\u0026#34; password = \u0026#34;PASSWORD\u0026#34; port = \u0026#34;443\u0026#34; datacenters = \u0026#34;24xSiempre\u0026#34; # Opcional cuando configures con VSAN File Services #targetvSANFileShareDatastoreURLs = \u0026#34;ds:///vmfs/volumes/vsan:52635b9067079319-95a7473222c4c9cd/\u0026#34; ```text vsphere.conf ```ini [Global] cluster-id = \u0026#34;kubernetes\u0026#34; [VirtualCenter \u0026#34;vcenter.24xsiempre.cl\u0026#34;] insecure-flag = \u0026#34;true\u0026#34; user = \u0026#34;administrator@vsphere.local\u0026#34; password = \u0026#34;PASSWORD\u0026#34; port = \u0026#34;443\u0026#34; datacenters = \u0026#34;24xSiempre\u0026#34; ```text Ahora te preguntaras por que estamos generando dos archivos con el mismo contenido pero de distinto nombre? es netamente para el primero utilizarlo como \u0026#34;secret\u0026#34; o almacenar los datos de autenticación como tambien si quieres agregar otras configuraciones, como por ejemplo para VSAN y el segundo archivo es para la creación del \u0026#34;configmap\u0026#34; para almacenar estas variables y disponibilizarlas al cluster. Por tanto creamos estos archivos en el servidor **MASTER** ```text nano csi-vsphere.conf nano vsphere.conf ```bash Guardas los archivos y los ejecutaremos en el server MASTER ```bash kubectl create secret generic vsphere-config-secret --from-file=csi-vsphere.conf --namespace=kube-system kubectl create configmap cloud-config --from-file=vsphere.conf --namespace=kube-system ```bash Ahora que tenemos configurada las credenciales y variables, realizaremos la configuración del CSI para en un inicio conseguir el \u0026#34;ProviderID\u0026#34;, primero debemos dejar los nodos en \u0026#34;Taint\u0026#34; para ello ejecutaremos en el **MASTER** ```bash kubectl taint nodes --all \u0026#39;node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule\u0026#39; ```bash Y luego ejecutar lo siguiente para configurar ```bash kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-roles.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml kubectl apply -f https://github.com/kubernetes/cloud-provider-vsphere/raw/master/manifests/controller-manager/vsphere-cloud-controller-manager-ds.yaml ```bash Y validaremos si se genera la configuracion y obtenemos el \u0026#34;ProviderID\u0026#34;, con el comando ```bash kubectl describe nodes | grep \u0026#34;ProviderID\u0026#34; ```bash Ahora instalaremos el driver CSI version 2.1.1 con lo siguiente: ```bash kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/v2.1.1/manifests/v2.1.1/vsphere-7.0u1/vanilla/rbac/vsphere-csi-controller-rbac.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/v2.1.1/manifests/v2.1.1/vsphere-7.0u1/vanilla/deploy/vsphere-csi-node-ds.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/v2.1.1/manifests/v2.1.1/vsphere-7.0u1/vanilla/deploy/vsphere-csi-controller-deployment.yaml kubectl get CSINode ```bash Ya que tenemos nuestro driver instalado debemos crear el Storage Class para utilizar nuestros datastore de vSphere y generar los volúmenes o First Class Disk, antes de esto hay que generar un Storage Policy Name en vCenter asociado al datastore que utilizaremos para albergar los volúmenes persistentes Y luego generamos el Storage Class ```bash cat \u0026lt;\u0026lt; EOF | kubectl apply -f - kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: csi-sc-vmc annotations: storageclass.kubernetes.io/is-default-class: \u0026#34;true\u0026#34; provisioner: csi.vsphere.vmware.com parameters: StoragePolicyName: \u0026#34;Contenedores\u0026#34; datastoreURL: \u0026#34;ds:///vmfs/volumes/60634600-6fcc5d36-bd83-dcfe07e145f9/\u0026#34; EOF ```bash En datastoreURL debes ingresar la direccion que se encuentra en el resumen del datastore en vCenter Y tendrás el resultado Ahora revisaremos que el Storage Class este correcto y crearemos un disco de prueba ```bash kubectl get sc ```bash Ahora creamos un disco de 5 gigas ```bash cat \u0026lt;\u0026lt; EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pruebasc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: csi-sc-vmc EOF Al ejecutar lo anterior, podremos ver la creación del disco en vCenter\nY ya con esto tienes un cluster kubernetes utilizando como almacenamiento de los volúmenes persistentes la plataforma de vSphere, para luego respaldarlo con Kasten, que en un próximo post revisaremos como respaldar múltiples cluster utilizando Kasten MultiCluster\nPosts relacionados # Como Instalar vSphere CSI Driver en RedHat OpenShift 4.x Red Hat OpenShift en vSphere con Kasten Como Integrar Active Directory con Kasten K10 y OpenShift Veeam + Kasten ","date":"4 de junio de 2021","externalUrl":null,"permalink":"/es/posts/instalar-cluster-de-kubernetes-con-vsphere-csi/","section":"Blog","summary":"En esta guía revisaremos la instalación y configuración de un cluster Kubernetes sobre Ubuntu 20.04 utilizando containerd, calico, realizando la integración vía vSphere CSI (Container Storage Interface) para proveer los volúmenes persistentes para los contenedores que funcionarán en el cluster. Ademas utilizaremos MetalLB como balanceador de carga para acceder a nuestros servicios.","title":"Instalar Cluster de Kubernetes con vSphere CSI","type":"posts"},{"content":"","date":"4 de junio de 2021","externalUrl":null,"permalink":"/es/tags/kubernetes/","section":"Etiquetas","summary":"","title":"Kubernetes","type":"tags"},{"content":"","date":"4 de junio de 2021","externalUrl":null,"permalink":"/es/tags/storageclass/","section":"Etiquetas","summary":"","title":"Storageclass","type":"tags"},{"content":"","date":"25 de marzo de 2021","externalUrl":null,"permalink":"/es/tags/respaldo-weblogic/","section":"Etiquetas","summary":"","title":"Respaldo-Weblogic","type":"tags"},{"content":" En este post revisaremos como realizar la protección de datos de uno de los servidores de aplicaciones más utilizados en grandes empresas, Oracle Weblogic, donde lo respaldaremos con Veeam Backup \u0026amp; Replication manteniendo la buena práctica recomendada por Oracle.\nComo siempre debemos ir a la documentación oficial de Oracle Weblogic donde encontraremos las buenas practicas y opciones recomendadas para realizar el respaldo de datos específicos de Oracle Weblogic\nhttps://docs.oracle.com/en/middleware/standalone/weblogic-server/14.1.1.0/index.html\nLuego de leer la documentación, ya sabemos que existen dos tipos de respaldos como también la protección de carpetas especificas de Oracle Weblogic\nOffline Backup Online Backup Y si en el caso de la instalación aplica se debe incluir los \u0026ldquo;Backup Artifacts\u0026rdquo; que son simplemente otras carpetas de configuración del sistema operativo.\nRespaldo con Veeam Backup \u0026amp; Replication # Para respaldar Oracle Weblogic con Veeam Backup \u0026amp; Replication es muy simple, ya que si la máquina sea física o virtual, la metodología de respaldo será vía Snapshot (utilizando las opciones por defecto), lo cual incluirá todos los archivos necesarios para realizar la recuperación de Oracle Weblogic en caso de algún problema en el servidor aplicativo.\nAhora como siempre hay que realizar los respaldos como lo indica la documentación oficial, es por ello que revisaremos las rutas de archivos y carpetas que se deben respaldar para una recuperación exitosa ya sea granular o con las grandes características de Veeam Backup \u0026amp; Replication.\nComo revisamos anteriormente, existen dos tipos de respaldo Offline y Online, como lo dice el mismo nombre para el respaldo Offline, es obligatorio bajar todos los servicios de Oracle Weblogic y luego respaldar los Backup Artifacts, es decir, los archivos o carpetas, para luego subir los servicios, en estos tiempos (a menos que sea necesario) posiblemente no sea la mejor opción por que tendremos baja del servicio y eso es inaceptable hoy en día no?.\nEs por ello que revisaremos el respaldo Online que es la mejor opción y no tiene bajas de servicio de Oracle Weblogic, por tanto, al revisar la documentación oficial, debemos asegurar que a la hora que se ejecute el respaldo no exista ningún cambio de configuración para que el respaldo se mantenga consistente.\nY por supuesto la recuperación es en base a los archivos de configuración de Weblogic, vía Instant VM Recovery o el mecanismo que requieras de Veeam Backup \u0026amp; Replication.\nPosts relacionados # Veeam Oracle RMAN Plugin Buenas Prácticas Veeam Plugin Oracle RMAN Protegiendo Oracle KVM con Veeam Veeam Capacity Tier Oracle Cloud Object Storage ","date":"25 de marzo de 2021","externalUrl":null,"permalink":"/es/posts/veeam-oracle-weblogic/","section":"Blog","summary":"En este post revisaremos como realizar la protección de datos de uno de los servidores de aplicaciones más utilizados en grandes empresas, Oracle Weblogic, donde lo respaldaremos con Veeam Backup \u0026 Replication manteniendo la buena práctica recomendada por Oracle.","title":"Veeam Oracle Weblogic","type":"posts"},{"content":"","date":"25 de marzo de 2021","externalUrl":null,"permalink":"/es/tags/veeam-backup-weblogic/","section":"Etiquetas","summary":"","title":"Veeam-Backup-Weblogic","type":"tags"},{"content":"","date":"25 de marzo de 2021","externalUrl":null,"permalink":"/es/tags/veeam-weblogic/","section":"Etiquetas","summary":"","title":"Veeam-Weblogic","type":"tags"},{"content":"","date":"25 marzo 2021","externalUrl":null,"permalink":"/en/tags/weblogic-backup/","section":"Tags","summary":"","title":"Weblogic-Backup","type":"tags"},{"content":"","date":"16 marzo 2021","externalUrl":null,"permalink":"/en/tags/openshift-backup/","section":"Tags","summary":"","title":"Openshift-Backup","type":"tags"},{"content":"","date":"16 de marzo de 2021","externalUrl":null,"permalink":"/es/tags/openshift-vmware/","section":"Etiquetas","summary":"","title":"Openshift-Vmware","type":"tags"},{"content":" Una de las plataformas más usadas en las empresas para la gestión, operación y mantención de Contenedores es Red Hat OpenShift, en la siguiente guía revisaremos como proteger nuestros contenedores en Red Hat OpenShift 4.x integrado VMware vSphere a través de su Container Storage Interface con Kasten K10 Platform, configurando rutas para acceder a la interfaz de administración de K10 y utilizando Minio S3 como destino de los respaldos.\nPasos Inciales # Como siempre debemos comenzar con la revisión de la documentación oficial de las aplicaciones, primero comenzaremos por Red Hat OpenShift 4.7 (Última versión a la fecha de esta guia):\nhttps://docs.openshift.com/container-platform/4.7/installing/installing_vsphere/installing-vsphere-installer-provisioned.html\nDonde la documentación indica los requerimientos y forma de instalación de Red Hat OpenShift 4.7 a través de IPI (Installer Provisioned Infrastructure) donde se ejecuta el instalador y solo debemos ingresar los datos solicitados de VMware vCenter. En este post no explicare como instalar OpenShift ya que con IPI es muy facil realizarlo. Si debemos revisar una parte de la documentacion muy importante de OpenShift en relacion a los volumenes\nhttps://docs.openshift.com/container-platform/4.7/storage/persistent_storage/persistent-storage-vsphere.html#vsphere-pv-backup_persistent-storage-efs\nEl Storage Class por defecto que se configura en OpenShift a través de IPI es de nombre \u0026ldquo;thin\u0026rdquo; utilizando kubernetes.io/vsphere-volume donde al requerir algún volumen persistente para los contenedores, este storage class, nos proveerá de discos independientes y persistentes desde vSphere, por tanto, como sabemos, no podremos realizar snapshots a esos volúmenes, por eso es importante revisar la documentación que nos antecede.\nY por supuesto revisar la documentación de Kasten K10 Platform, actualmente en la versión 3.0.9 (a la fecha de esta post) para los requerimientos y pasos de instalación en Red Hat OpenShift\nhttps://docs.kasten.io/latest/index.html\nInstalación Kasten OpenShift 4.x # Antes de instalar Kasten en cualquier distribución de Kubernetes, siempre debemos realizar la ejecución de un script para realizar chequeos previos a la instalacion y validar si tenemos soporte de las caracterisitcas de Kasten K10, con el siguiente comando:\ncurl https://docs.kasten.io/tools/k10_primer.sh | bash ```bash Si no encuentra el ejecutable helm, pueden ver la la instalación de los requisitos previos en el link en la parte de instalacion de Kasten: [/veeam-kasten/](/veeam-kasten/) Ahora ya que tenemos los requisitos previos, helm, kubectl, vSphere CSI (en este caso la versión 2.1.1) comenzaremos con la instalacion de Kasten K10, como lo indica la documentacion debemos realizar dos comandos: ```bash helm repo add kasten https://charts.kasten.io/ kubectl create namespace kasten-io ```bash Ya tenemos todo pre-configurado, solo nos falta la instalación, como se indica en la documentación de Kasten, realizaremos el siguiente comando ```bash helm install k10 kasten/k10 --namespace=kasten-io \\ --set scc.create=true ```bash Como se ve en la imagen anterior, ya tenemos instalado nuestro Kasten K10 sobre OpenShift, ahora revisaremos el estado de los pods con el comando: ```bash watch oc get pods -n kasten-io ```bash Debemos esperar que todos los pods de Kasten se encuentren en estado \u0026#34;running\u0026#34; Y si revisamos los volumenes persistentes que usa Kasten desde la linea de comandos: ```bash oc get pv,pvc Observamos que esta utilizando el Storage Class, vsphere-csi, y asociado a los volúmenes que también podemos observar en en el datastore que utilizamos en vCenter:\nAsi como tambien en la consola de Red Hat OpenShift\nAcceso K10 Dashboard a través de Ruta en OpenShift # Para acceder a la consola de administracion de Kasten K10, solo debemos realizar una ruta en OpenShift para exponer nuestro servicio, en este caso lo realizaremos a traves de la consola Web de Red Hat OpenShift, vamos Networking -\u0026gt; Routes y en la esquina superior izquierda seleccionamos el proyecto \u0026ldquo;kasten-io\u0026rdquo;\nAquí realizaremos la creación de la Ruta haciendo clic en \u0026ldquo;Create Route\u0026rdquo; e ingresaremos la siguiente informacion:\nName: El nombre que quieras en este caso \u0026ldquo;k10\u0026rdquo; Hostname: lo dejamos en blanco para que nos asigne un hostname o ingresas uno que quieras Path: por defecto Service: Seleccionar el servicio \u0026ldquo;gateway\u0026rdquo; Target Port: Seleccionar el único que despliega, si no, solo 8000 -\u0026gt; 8000 TCP Y luego al hacer clic en \u0026ldquo;Create\u0026rdquo; nos mostrara los detalles y el link de acceso que se ve en \u0026quot; Location\u0026quot;\nLuego hacen clic o copiar la direccion URL que se encuentra en \u0026quot; Location\u0026quot; y le agregan \u0026ldquo;/k10/#/\u0026rdquo; para acceder a la consola de administracion, la url en mi caso quedaria:\nhttp://k10-kasten-io.apps.oc.24xsiempre.cl/k10/#/\nY al acceder a la URL veremos la consola y mensaje de bienvenida de Kasten:\nIngresamos nuestros datos y procederemos a configurar nuestra solución de Kasten K10 Platform.\nConfiguración Kasten K10 con Minio S3 # Primero instalaremos Minio sobre Ubuntu, donde puedes seguir una de las múltiples guías muy simples de configurar por ejemplo:\nhttps://www.digitalocean.com/community/tutorials/how-to-set-up-an-object-storage-server-using-minio-on-ubuntu-18-04-es\nLuego de tener operativo Minio S3, realizaremos la configuracion de Kasten k10 ingresando en \u0026ldquo;Settings\u0026rdquo; para agregar un nuevo \u0026ldquo;Profile\u0026rdquo;\nDonde ingresaremos el nombre del perfil y selecionaremos \u0026ldquo;S3 Compatible\u0026rdquo; para usar con Minio\nProfile Name: openshift, o puede ser el nombre que desees Cloud Storage Provider: S3 Compatible, para usar con Minio debe ser esta opcion, de lo contrario puedes usar la que necesites S3 Access Key: Access key, de Minio o tu proveedor de almacenamiento de objetos S3 Secret: Secret o Password, de Minio o tu proveedor de almacenamiento de objetos Endpoint: http://40.40.40.100:9000/ , o la direccion de tu servidor minio Skip Certificate chain and hostname verification: Habilitado, ya que no estamos usando SSL en este caso. Region: Dejar en Blanco Bucket Name: openshift, nombre del bucket a utilizar Y la configuración se mostrará así:\nConfiguración Kasten K10 con vSphere vCenter # Ingresando en \u0026ldquo;Settings\u0026rdquo; y seleccionando \u0026ldquo;Infrastructure\u0026rdquo; generaremos un nuevo \u0026ldquo;Profile\u0026rdquo;\nDonde\nProfile Name: vcenter, o el nombre que quieras Infrastructure Type: vSphere vCenter Server: direccion ip o dns de vcenter, de preferencia fqdn vSphere User: usuario vcenter con privilegios vSphere Password: password Y ya teniendo todo esto configurado podrás realizar los respaldos utilizando la interfaz CSI para vSphere creando snapshots de los volúmenes persistentes que existen en los datastores configurados.\nY por supuesto la generación de políticas de respaldos con Kasten k10 la puedes revisar en /veeam-kasten/\nPosts relacionados # Como Instalar vSphere CSI Driver en RedHat OpenShift 4.x Como Integrar Active Directory con Kasten K10 y OpenShift Instalar Cluster de Kubernetes con vSphere CSI Kasten K10 Authentik Kasten K10 Multi-Cluster Veeam + Kasten ","date":"16 de marzo de 2021","externalUrl":null,"permalink":"/es/posts/red-hat-openshift-en-vsphere-con-kasten/","section":"Blog","summary":"Una de las plataformas más usadas en las empresas para la gestión, operación y mantención de Contenedores es Red Hat OpenShift, en la siguiente guía revisaremos como proteger nuestros contenedores en Red Hat OpenShift 4.x integrado VMware vSphere a través de su Container Storage Interface con Kasten K10 Platform, configurando rutas para acceder a la interfaz de administración de K10 y utilizando Minio S3 como destino de los respaldos.","title":"Red Hat OpenShift en vSphere con Kasten","type":"posts"},{"content":"","date":"16 de marzo de 2021","externalUrl":null,"permalink":"/es/tags/respaldo-openshift/","section":"Etiquetas","summary":"","title":"Respaldo-Openshift","type":"tags"},{"content":"","date":"16 de marzo de 2021","externalUrl":null,"permalink":"/es/tags/vsphere/","section":"Etiquetas","summary":"","title":"VSphere","type":"tags"},{"content":"","date":"25 de febrero de 2021","externalUrl":null,"permalink":"/es/tags/backup-immutable/","section":"Etiquetas","summary":"","title":"Backup-Immutable","type":"tags"},{"content":"","date":"25 de febrero de 2021","externalUrl":null,"permalink":"/es/tags/hardened-linux-repository-veeam/","section":"Etiquetas","summary":"","title":"Hardened-Linux-Repository-Veeam","type":"tags"},{"content":"","date":"25 febrero 2021","externalUrl":null,"permalink":"/en/tags/immutable-backup/","section":"Tags","summary":"","title":"Immutable-Backup","type":"tags"},{"content":"","date":"25 de febrero de 2021","externalUrl":null,"permalink":"/es/tags/immutable-ransomware/","section":"Etiquetas","summary":"","title":"Immutable-Ransomware","type":"tags"},{"content":"","date":"25 de febrero de 2021","externalUrl":null,"permalink":"/es/tags/linux-repository/","section":"Etiquetas","summary":"","title":"Linux-Repository","type":"tags"},{"content":"","date":"25 de febrero de 2021","externalUrl":null,"permalink":"/es/tags/respaldo-inmutable/","section":"Etiquetas","summary":"","title":"Respaldo-Inmutable","type":"tags"},{"content":" Tremenda noticia con el lanzamiento de la versión 11 de Veeam Availability Suite que contiene más de 200 mejoras, Replicación sin Snapshots CDP, Instant Recovery para NAS / Bases de Datos y también Veeam Hardened Repository. En este post nos centraremos en la instalación, configuración en detalle de este nuevo tipo de repositorio que nos permitirá mantener nuestros respaldos inmutables!\nPasos Iniciales # Como es de costumbre, siempre revisaremos la documentación oficial de Veeam, para este caso del Repositorio Linux Inmutable:\nhttps://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository.html?ver=110\nDonde podremos ver todos los requerimientos para esta característica donde una de las más importantes es que las tareas de respaldos deben usar Forward Incremental con respaldos Full o Synthetic para el correcto funcionamiento de la inmutabilidad.\nLuego de leer la documentación pasamos a la instalación base de un Linux Ubuntu 20.04 LTS y luego de finalizar, nos conectamos por SSH y realizamos la actualización del sistema operativo:\nsudo apt-get update -y sudo apt-get upgrade -y ```json Luego de la actualización, apagaremos el servidor Linux con el comando: ```bash sudo poweroff ```bash En mi caso, al ser una maquina virtual, agregare un disco del tamaño necesario para utilizarlo como repositorio, por tanto, editamos la configuración de la VM y agregaremos un disco (para este LAB agregaré un disco de 2 TB) y luego encendemos la maquina: ## Veeam Repo Manager Nuevamente nos conectamos vía SSH y en este caso utilizaremos una gran herramienta, Veeam Repo Manager, para facilitar aun mas la configuración del repositorio inmutable de Veeam, que se encuentra en el Github de Timothy Dewin, Arquitecto de Soluciones en Veeam: [https://github.com/tdewin/veeamhubrepo](https://github.com/tdewin/veeamhubrepo) Esta herramienta nos permite configurar de manera visual todos los requerimientos para conseguir la configuración correcta del repositorio, por tanto, procederemos a instalarla. ## Instalación y Configuración Ya que estamos conectados via SSH al servidor Linux Ubuntu 20.04 LTS y tambien agregamos disco para almacenar los respaldos debemos ejecutar lo siguiente: ```bash sudo wget -O ./veeamhubrepo.deb https://github.com/tdewin/veeamhubrepo/releases/download/v0.3.1/veeamhubrepo_noarch.deb sudo apt-get install ./veeamhubrepo.deb sudo veeamhubrepo ```bash Y con el último comando que ejecutamos \u0026#34;sudo veeamhubrepo \u0026#34; nos mostrará el asistente de esta herramienta: Donde seleccionaremos \u0026#34;Yes\u0026#34; presionando \u0026#34;Enter\u0026#34; para luego ingresar el nombre de usuario que tendrá los privilegios momentáneos para usar la inmutabilidad, por defecto es \u0026#34;veeamrepo\u0026#34;, si deseas cambiarlo, hazlo de acuerdo a tus nomenclatura de usuarios, si no, déjalo por defecto: Luego seleccinamos \u0026#34;OK\u0026#34; para que nos indique que no existe el usuario y confirmar la creación de éste: Seleccionamos \u0026#34;Yes\u0026#34; e ingresamos la contraseña para este usuario: Luego nos confirmará que el usuario fue creado y seleccionamos \u0026#34;OK\u0026#34; para que pasemos a la configuración de la partición del disco agregado: En este LAB necesito seleccionar el disco numero \u0026#34;3\u0026#34; el cual agregamos adicionalmente de 2 TB, moviéndonos con las flechas del teclado y luego presionamos \u0026#34;Enter\u0026#34;, en tu caso debes seleccionar el disco que agregaste: Confirmamos la selección y luego \u0026#34;OK\u0026#34; Luego de confirmar y aplicar los cambios nos indicara en que ruta o path montará el disco: Si deseas cambiar el path o ruta es posible editarlo, en nuestro caso lo dejaremos por defecto en /backups/repo001 y seleccionaremos \u0026#34;OK\u0026#34; para que nos confirme la creación y montaje: Después de la configuración del disco donde se almacenarán los respaldos con características de inmutabilidad, viene una parte muy importante para configurar la hora y zona horaria y seleccionamos \u0026#34;Yes\u0026#34;: En mi caso seleccionaré: ```text /usr/share/zoneinfo/Chile/Continental ```json Al seleccionar y presionar Enter en \u0026#34;OK\u0026#34; nos confirmará la configuración: Luego al Seleccionar \u0026#34;OK\u0026#34; nos preguntará por nuestro servicio NTP, que puede ser local o vía internet Luego nos mostrará si deseamos actualizar Al finalizar perderás conexión con el servidor, por tanto nos conectaremos a través de la consola Web de vCenter y ejecutaremos el comando: ```bash sudo veeamhubrepo Acceso sin SSH # Y procederemos a Registrar nuestro nuevo repositorio, seleccionando la opción \u0026ldquo;3\u0026rdquo; y confirmamos que inicie el servicio SSH:\nY nos indicará que nos conectemos con las credenciales que creamos anteriormente desde Veeam Backup Replication y lo agregamos como repositorio:\nCreación Repositorio Veeam Backup \u0026amp; Replication # Desde Veeam Backup \u0026amp; Replication, agregaremos el repositorio:\nY como vemos en la imagen anterior seleccionaremos \u0026ldquo;Single-use credentials for hardened repository\u0026hellip;\u0026rdquo; en ingresamos las credenciales\nLuego hacemos clic en \u0026ldquo;Next\u0026rdquo; y confirmamos:\nPara terminar viendo el resumen de la configuración:\nMientras se realiza la configuración desde Veeam Backup \u0026amp; Replication la utilidad Repo Manager detecta el proceso de Veeam\nY luego seguimos con la configuración del repositorio seleccionando la partición para alojar los respaldos\nY aquí es la parte mas importante para este tipo de repositorio, esta herramienta realiza la configuración de la partición con XFS habilitando reflink para aprovechar las características cuando realicemos Synthetic Full por ejemplo y ademas habilitar la opción para hacer inmutables los respaldos por los días que sea necesario, por defecto son 7 días:\nAquí es donde la magia aparece, como se observas en la imagen anterior\nLuego lanzamos un nuevo respaldo al nuevo Hardened Linux Repository\nPruebas Eliminación Respaldo # Ya que tenemos un respaldo en el repositorio y anteriormente activamos la inmutabilidad en el repositorio, revisaremos si es posible eliminar respaldos, por tanto, en Veeam Backup Server, iremos al respaldo y eliminaremos el archivo:\nLuego de confirmar la eliminación, aparece la ventana de estado de la operación donde observaremos que NO es posible eliminar el archivo de respaldo y ademas nos indica el día (03/03/2021 20:02) cuando se desactiva esta inmutabilidad, ya que lo habilitamos por 7 días:\nInclusive si accedes al servidor no podrás eliminar el archivo ya que cuenta con el parámetro avanzado +i que inclusive root no puede eliminar.\nYa se que en este momento estas pensando, y si root le quita el parámetro +i, y eliminar, si es posible, lo importante aquí es que las credenciales de este servidor y los métodos de acceso sean totalmente restringidos para que desde la red no sean alcanzados los archivos de respaldo y sean eliminados por algún agente malicioso.\nAdemas, esta solución, mantiene un demonio en el servidor linux para utilizar la logica de inmutabilidad y realizar los cambios de acuerdo a los dias de inmutabilidad que hayas configurado.\nCon esto terminamos este post en detalle para la configuracion de inmutabilidad con el nuevo tipo de repositorio para Veeam Backup \u0026amp; Replication llamado Linux Hardened Repository.\nPosts relacionados # Veeam Immutable Repository con Red Hat Enterprise Linux Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam Plan de Respuesta ante Incidentes con NIST 800-61, 800-53r5, Mitre ATT\u0026amp;CK y Veeam Veeam Decoys - Detección Temprana JADI Scanner vScan Vulnerability Scanner 2.0 ","date":"25 de febrero de 2021","externalUrl":null,"permalink":"/es/posts/veeam-hardened-immutable-repository/","section":"Blog","summary":"Tremenda noticia con el lanzamiento de la versión 11 de Veeam Availability Suite que contiene más de 200 mejoras, Replicación sin Snapshots CDP, Instant Recovery para NAS / Bases de Datos y también Veeam Hardened Repository. En este post nos centraremos en la instalación, configuración en detalle de este nuevo tipo de repositorio que nos permitirá mantener nuestros respaldos inmutables!","title":"Veeam Hardened (Immutable) Repository","type":"posts"},{"content":"","date":"25 de febrero de 2021","externalUrl":null,"permalink":"/es/tags/veeam-ransomware-prevention/","section":"Etiquetas","summary":"","title":"Veeam-Ransomware-Prevention","type":"tags"},{"content":"","date":"9 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/actualizar-veeam-aws/","section":"Etiquetas","summary":"","title":"Actualizar-Veeam-Aws","type":"tags"},{"content":"","date":"9 diciembre 2020","externalUrl":null,"permalink":"/en/tags/amazon-rds-backup/","section":"Tags","summary":"","title":"Amazon-Rds-Backup","type":"tags"},{"content":"","date":"9 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/respaldo-amazon-rds/","section":"Etiquetas","summary":"","title":"Respaldo-Amazon-Rds","type":"tags"},{"content":"","date":"9 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/respaldo-vpc/","section":"Etiquetas","summary":"","title":"Respaldo-Vpc","type":"tags"},{"content":"","date":"9 diciembre 2020","externalUrl":null,"permalink":"/en/tags/upgrade-veeam-aws/","section":"Tags","summary":"","title":"Upgrade-Veeam-Aws","type":"tags"},{"content":" Excelente noticia sobre el lanzamiento de la nueva versión de Veeam Backup for AWS v3 que trae características necesarias para la protección de instancias, protección de la configuración VPC y bases de datos Amazon RDS, en este post veremos como actualizar a la ultima versión y realizar respaldos con las nuevas características.\nPasos Inciales # Entonces comenzaremos como siempre revisando la documentación oficial de Veeam Backup for AWS v3 que la podemos encontrar en:\nhttps://helpcenter.veeam.com/docs/vbaws/guide/welcome.html?ver=30\nPrimero veremos las nuevas funcionalidades que nos trae esta nueva versión:\nRespaldo para Amazon RDS Respaldo para la configuración de VPC Acceso por RBAC Mejoras en la Recuperación Granular de Archivos AWS Outpost Por supuesto el respaldo y replicación de snapshots de instancias existentes en AWS que ya viene desde la v1 y v2 respectivamente.\nEntrando en detalle, el soporte para respaldos de Amazon RDS incluye:\nMicrosoft SQL Server Oracle MariaDB MySQL PostgreSQL Con respecto al respaldo de configuración de VPC, permite proteger todos los elementos dentro del VPC, incluyendo security groups. subnets, etc. Algo extremadamente importante es que nos permitirá comparar las configuraciones que tenemos en el respaldo versus la que están actualmente siendo usadas, así en caso de algún modificación podremos saber que fue modificado en producción :)\nPara Role Based Access Control, esta nueva versión incluye los roles\nPortal Administrator Portal Operator Restore Operator Lo cual nos permite mantener una segregación de usuarios para la gestión de Veeam Backup for AWS v3.\nActualizar Veeam Backup AWS # Esto es muy sencillo, si es primera vez que utilizaras Veeam Backup for AWS v3, solo debes instalarlo desde el marketplace de AWS y si ya tienes la versión 2 debes ingresar a \u0026ldquo;Configuration\u0026rdquo; luego \u0026ldquo;Support Information\u0026rdquo;:\nY luego al hacer clic en \u0026ldquo;Check and view updates\u0026rdquo;, nos abrirá una pagina que nos mostrara el detalle de la actualización\nLuego seleccionar la versión 3, instale las actualizaciones y reinicie automáticamente si es necesario, para hacer clic en \u0026ldquo;Install Updates Now\u0026rdquo;\nLuego iniciamos sesión nuevamente y nos mostrara lo siguiente:\nY con eso finalizamos la actualización de Veeam Backup for AWS v3, muy fácil no? :)\nAntes de comenzar a utilizar las nuevas características, es muy importante mencionarles que Veeam Backup for AWS v3 siempre nos permitirá chequear los permisos que tenga el rol para poder realizar el respaldo ya sea de EC2, RDS o VPC, así que como consejo, cuando estén generando una nueva política de protección, siempre chequeen los permisos y aparecerá algo así\nDonde al hacer clic en \u0026ldquo;Grant\u0026rdquo; solicitará una credencial temporal que tenga permisos de administración para asignar lo necesario\nY luego de hacer clic en \u0026ldquo;Apply\u0026rdquo; verán los permisos correctamente asignados\nRespaldo Amazon RDS # Esta característica es clave, ya que muchos necesitamos realizar los respaldos de nuestra bases de datos que se ejecutan en Amazon RDS y con Veeam Backup for AWS podremos protegerlo, primero debemos hacer clic en \u0026ldquo;Policies\u0026rdquo; y veremos lo siguiente\nComo podemos observar en la imagen anterior, existentes opciones, EC2, RDS y VPC, seleccionando EC2 nos permitirá realizar respaldo de todas nuestras instancias que existan y tengamos permisos para acceder, algo clave aquí es que nos permitirá realizar respaldo consistentes de nuestras instancias a nivel aplicativo como también si es necesario ejecutar scripts pre y post respaldo.\nEn RDS no permitirá realizar respaldos de las bases de datos que tengamos en el servicio de Amazon RDS, en este caso tengo configurada una base de datos de MariaDB y un snapshot existente de MySQL, por tanto haremos clic en RDS y luego en \u0026ldquo;Add\u0026rdquo;\nDespués de ingresar el nombre de la política, seleccionaremos, el rol a utilizar, región y que recursos proteger (Recuerda siempre chequear permisos como lo revisamos anteriormente)\nLuego si deseamos o no replicar los snaphost, en este caso no lo configurare, pero sabemos que es muy simple. A continuación seguimos a \u0026ldquo;Schedule\u0026rdquo; y configuramos la agenda de ejecución\nLuego veremos el costo, esta característica es hermosa, ya que puedes saber cuanto costara el respaldo antes de realizarlos, así no te encontraras con sorpresas y cuando hablamos de usar recursos en cloud, siempre debemos tener una mirada al presupuesto\nLuego las configuraciones de reintento y por ultimo finalizar la creación de la política de respaldo\nEjecutaremos el respaldo, seleccionando la política y haciendo clic en \u0026ldquo;Start\u0026rdquo;\nY veremos la ejecución exitosa.\nRecuperación Amazon RDS # Ya tenemos respaldo, ahora necesitamos recuperar nuestra base de datos en Amazon RDS, primero eliminare mi base de datos db24xsiempre\nLuego volvemos a Veeam Backup for AWS, y hacemos clic en \u0026ldquo;Protected Data\u0026rdquo; y seleccionamos RDS para ver nuestras bases de datos\nSeleccionamos la base de datos, en este caso, db24xsiempre y hacemos clic en \u0026ldquo;Restore Instance\u0026rdquo;, donde nos permitirá seleccionar el punto de restauración para dicha base de datos\nLuego hacemos clic en \u0026ldquo;Next\u0026rdquo; y seleccionamos el rol que utilizaremos para recuperar, recuerda siempre chequear permisos y pasamos a la siguiente pantalla donde nos indicara donde queremos recuperar\nY por último vemos el resumen de lo que se realizará\nLuego vemos el estado de recuperación en \u0026ldquo;Sessions Log\u0026rdquo;\nY si revisamos la consola de AWS podremos ver\nSe esta creando la instancia de Amazon RDS MariaDB como solicitamos la recuperación, si observaste bien, el nombre de la instancia es temporal para la recuperación, luego de unos minutos tendremos\nY en la consola de Amazon RDS\nRespaldo Configuración VPC # En este caso, Veeam Backup for AWS automáticamente genera una política de respaldo de todo el VPC, manteniéndola deshabilitada para que si es necesario realizar el respaldo solo se habilite y se realice el respaldo de toda la configuración del VPC\nPor tanto, debemos habilitarla, seleccionando la política y haciendo clic en \u0026ldquo;Enable\u0026rdquo;\nY ya queda habilitada la política, luego la editamos para asignar mas VPC de otras regiones o solo proteger la actual, haciendo clic en \u0026ldquo;Edit\u0026rdquo; veremos\nY al hacer clic en \u0026ldquo;Next\u0026rdquo; nos permitirá realizar el respaldo hacia nuestro repositorio de Veeam Backup for AWS en Amazon S3, habilitamos y seleccionamos nuestro repositorio, luego \u0026ldquo;Next\u0026rdquo;\nAquí seleccionaremos la retención del respaldo de la configuración de VPC de acuerdo a la necesidad de cada uno\nY por ultimo veremos el resumen de la configuración\nAhora ejecutamos la política y veremos las estadísticas\nY ya tenemos nuestro respaldo de la configuración de VPC :)\nRecuperación Configuración AWS VPC # Antes de recuperar, como mencione antes, hay una característica extremadamente importante para los administrados de AWS ya que al tener respaldada la configuración de VPC, Veeam Backup for AWS permite comparar la configuración existente en AWS versus la que tenemos en el respaldo, solo debemos hacer clic en \u0026ldquo;Compare\u0026rdquo;\nY podemos seleccionar que muestre solo los atributos que se hayan cambiado o te indicara que no hay diferencias entre producción y el respaldo. Y por ultimo si quieres exportas la configuración o la restauras, excelente!\nAhora veremos como restaurar toda la configuración o solo algunos elementos de configuración del VPC, seleccionamos el VPC que deseamos recuperar y haremos clic en \u0026ldquo;Restore\u0026rdquo;\nSi seleccionas \u0026ldquo;Selected Items\u0026rdquo; podrás recuperar granularmente las configuraciones de tu VPC\nO en mi caso realizare la recuperación completa de mi configuración VPC\nLuego seleccionamos el Rol con cual recuperaremos, siempre chequear los permisos\nRestauramos a la ubicación original o a una nueva\nY por ultimo el resumen\nPara finalizar con el estado de recuperación\nExcelente versión de Veeam Backup for AWS v3 que nos permite proteger nuestros recursos en AWS. Totalmente recomendado!\nPosts relacionados # Veeam Capacity Tier Oracle Cloud Object Storage Veeam Cloud Connect Performance Como Instalar Kasten K10 en AWS EKS Veeam + Kasten ","date":"9 de diciembre de 2020","externalUrl":null,"permalink":"/es/posts/veeam-backup-para-aws-v3/","section":"Blog","summary":"Excelente noticia sobre el lanzamiento de la nueva versión de Veeam Backup for AWS v3 que trae características necesarias para la protección de instancias, protección de la configuración VPC y bases de datos Amazon RDS, en este post veremos como actualizar a la ultima versión y realizar respaldos con las nuevas características.","title":"Veeam Backup para AWS v3","type":"posts"},{"content":"","date":"9 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/veeam-backup-aws/","section":"Etiquetas","summary":"","title":"Veeam-Backup-Aws","type":"tags"},{"content":"","date":"9 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/veeam-rds-mysql-respaldo/","section":"Etiquetas","summary":"","title":"Veeam-Rds-Mysql-Respaldo","type":"tags"},{"content":"","date":"9 diciembre 2020","externalUrl":null,"permalink":"/en/tags/vpc-backup/","section":"Tags","summary":"","title":"Vpc-Backup","type":"tags"},{"content":"","date":"2 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/citrix/","section":"Etiquetas","summary":"","title":"Citrix","type":"tags"},{"content":"","date":"2 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/migracion-xenserver/","section":"Etiquetas","summary":"","title":"Migracion-Xenserver","type":"tags"},{"content":"","date":"2 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/recuperacion-xenserver/","section":"Etiquetas","summary":"","title":"Recuperacion-Xenserver","type":"tags"},{"content":"","date":"2 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/respaldo/","section":"Etiquetas","summary":"","title":"Respaldo","type":"tags"},{"content":" En este post veremos la forma de proteger las maquinas virtuales de Citrix XenServer o Citrix Hypervisor con Veeam v10 y sus respectivos agentes, permitiendo la recuperación en el mismo hipervisor o realizando recuperación o migración instantánea hacia VMware vSphere.\nIntroducción # Todos sabemos que los hipervisores soportados con integración (hasta el momento) por Veeam Backup \u0026amp; Replication son VMware y Hyper-V, por tanto, cuando hablamos de otros hipervisores como ejemplo Citrix XenServer (Citrix Hypervisor), Oracle VM, Proxmox por decir algunos, necesitaremos utilizar los Agentes de Veeam para realizar la protección completa de las maquinas virtuales.\nYa que debemos utilizar agentes, en este caso, usaremos Veeam Agent for Windows y Veeam Agent for Linux los cuales proveen una solución excelente para realizar el respaldo completo de las maquinas como también ofrecen consistencia aplicativa para bases de datos o aplicaciones en el caso que sea requerido.\nPor supuesto también existen otras opciones de respaldo de acuerdo a la necesidad de cada ambiente, los cuales puedes revisar en:\nVeeam Agent for Windows: https://helpcenter.veeam.com/docs/agentforwindows/userguide/backup_job_create.html?ver=40\nVeeam Agent for Linux: https://helpcenter.veeam.com/docs/agentforlinux/userguide/backup_job_create.html?ver=40\nAmbiente instalado de Citrix Hypervisor / XenServer # En el laboratorio instalé solo un nodo de hipervisor y su respectivo XenCenter para hacer las pruebas. Las versiones instaladas son las ultimas que pude descargar desde la pagina de Citrix:\nhttps://www.citrix.com/downloads/citrix-hypervisor/\nLa versión usada para el hipervisor y XenCenter es 8.2. Luego instale una maquina con Windows Server 2019 con Citrix VM Tools 9.0.42 y una con CentOS 8 con Citrix VM Tools 7.20.0-1 para luego realizar el respaldo de ambas maquinas.\nGrupo de Protección # Cuando hablamos de agentes con Veeam, siempre debemos administrarlos desde un grupo de protección ya que nos permite centralizar la gestión y ordenar de acuerdo a las necesidades de la empresa los distintos servidores que utilizaran agentes.\nComo se ve en la imagen anterior, vemos ambos servidores con sus respectivo agentes instalados, recuerda que al crear el grupo de protección, Veeam Backup \u0026amp; Replication realizara la instalación del agente ya sea para Windows o Linux automáticamente\nLuego de confirmar la instalación de los agentes, Veeam Agent for Windows o Veeam Agent for Linux, realizaremos los respectivos Job de respaldos, los cuales los configuraremos para respaldar toda la maquina para luego tener la opción de Bare Metal Recovery en el caso de que queramos recuperar completamente el servidor en XenServer o en VMware vSphere\nLuego ejecutamos el Job de Respaldo de ambos servidores y vemos las estadísticas cuando finalicen\nRecuperación de Imagen XenServer # Ahora viene lo importante, realizar la recuperación Bare Metal Restore ya sea de Linux o Windows hacia Citrix XenServer / Hypervisor, si quieres revisar el manual de Veeam para ver el procedimiento\nVAW: https://helpcenter.veeam.com/docs/agentforwindows/userguide/image_boot.html?ver=40\nVAL: https://helpcenter.veeam.com/docs/agentforlinux/userguide/baremetal.html?ver=40\nComo veras en el manual, para Windows necesitas crear la ISO de Recovery Media que lo puedes hacer directamente desde la consola y guardarla donde estimes conveniente realizando NNF\nY para el caso de respaldos con Veeam Agent for Linux, debes descargar la ISO de Recuperación desde la pagina de descargas de Veeam\nhttps://www.veeam.com/linux-backup-download.html\nLuego copias ambas ISOS al repositorio que tengas en Citrix\nY por ultimo generas una maquina virtual desde XenCenter con las mismas características de hardware virtual para realizar la recuperación\nLuego inicias la maquina virtual con la ISO conectada para realizar la recuperación\nSeleccionas \u0026ldquo;Network Storage\u0026rdquo; next, luego \u0026ldquo;Veeam Backup Repository\u0026rdquo; y le asignas una dirección IP donde dice \u0026ldquo;Configure Network Settings\u0026rdquo;\nLuego ingresamos los datos de nuestro repositorio de Veeam Backup \u0026amp; Replication\nSeleccionamos el respaldo que deseamos recuperar\nY seleccionamos recuperar \u0026ldquo;Entire Computer\u0026rdquo;\nY luego procedemos a la recuperación de la maquina virtual en Citrix XenServer / Hypervisor\nLuego reiniciar y remover ISO de recuperación para ver el inicio de Windows y revisar que las XenTools se ejecuten:\nY ya con esto finalizamos la recuperación de maquinas completas en XenServer.\nRecuperación hacia VMware # Una de las características más hermosas que posee Veeam Backup \u0026amp; Replication es la de recuperar cualquier respaldo directamente hacia VMware vSphere lo que nos permite mantener una estrategia multicloud e hibrida para la recuperación de datos, si quieres saber más\nhttps://helpcenter.veeam.com/docs/backup/vsphere/performing_instant_recovery_vm.html?ver=100\nPor tanto si quieres tener la opción de recuperar o migrar las maquinas virtuales de XenServer hacia VMware, lo puedes realizar con Instant Recovery directamente desde la consola de Veeam Backup \u0026amp; Replication\nAl hacer clic en Instant VM Recovery, nos mostrara el Wizard para la recuperación de la maquina de XenServer y luego seleccionamos el punto de Recuperación deseado:\nLuego de seleccionar el punto de restauración ingresaremos los datos de VMware que se solicitan para luego hacer NNF\nY podemos seleccionar si queremos encender la maquina y conectarlas a la red\nY veremos el estado de la recuperación:\nLuego queda a la espera para hacer la migración:\nLa maquina ya funciona!. Ahora realizaremos la migración al datastore productivo de vSphere, seleccionamos los recursos de vSphere que utilizaremos\nLuego utilizar proxies o dejarlos en automático\nPor ultimo ver el resumen de lo que se realizará\nY por ultimo las estadísticas\nPor tanto con Veeam Backup \u0026amp; Replication puedes proteger tus maquinas virtuales en Citrix XenServer / Hypervisor y recuperarlas completamente en el mismo Xen o recuperar / migrar hacia VMware vSphere.\nPosts relacionados # Veeam Backup for Red Hat Virtualization Protegiendo Oracle KVM con Veeam Proxmox Lab con ZimaBlade Veeam Agent Linux - Oracle Linux / Exadata ","date":"2 de diciembre de 2020","externalUrl":null,"permalink":"/es/posts/veeam-citrix-hypervisor-xenserver/","section":"Blog","summary":"En este post veremos la forma de proteger las maquinas virtuales de Citrix XenServer o Citrix Hypervisor con Veeam v10 y sus respectivos agentes, permitiendo la recuperación en el mismo hipervisor o realizando recuperación o migración instantánea hacia VMware vSphere.","title":"Veeam Citrix Hypervisor /  Xenserver","type":"posts"},{"content":"","date":"2 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/veeam-citrix/","section":"Etiquetas","summary":"","title":"Veeam-Citrix","type":"tags"},{"content":"","date":"2 de diciembre de 2020","externalUrl":null,"permalink":"/es/tags/xenserver/","section":"Etiquetas","summary":"","title":"XenServer","type":"tags"},{"content":"","date":"2 diciembre 2020","externalUrl":null,"permalink":"/en/tags/xenserver-backup/","section":"Tags","summary":"","title":"Xenserver-Backup","type":"tags"},{"content":"","date":"2 diciembre 2020","externalUrl":null,"permalink":"/en/tags/xenserver-migration/","section":"Tags","summary":"","title":"Xenserver-Migration","type":"tags"},{"content":"","date":"2 diciembre 2020","externalUrl":null,"permalink":"/en/tags/xenserver-recovery/","section":"Tags","summary":"","title":"Xenserver-Recovery","type":"tags"},{"content":"","date":"17 de noviembre de 2020","externalUrl":null,"permalink":"/es/tags/k10multicluster/","section":"Etiquetas","summary":"","title":"K10Multicluster","type":"tags"},{"content":" En la ultima versión de Kasten, 3.0.1, podemos encontrar una serie de mejoras y una solución extremadamente importante, la administración centralizada de Múltiples Clusters de Kubernetes para una protección de datos completa, en este post veremos las características y funcionalidades de k10multicluster.\nIntroducción # Como vimos en un post anterior, es necesario que se realice la actualización a la ultima versión de Kasten k10, la puedes encontrar:\nhttps://www.24xsiempre.com/actualizar-kasten-k10/\nLuego de completar la actualización, podremos pasar a la configuración de k10 Multi-Cluster, donde, como siempre, debemos revisar la documentación oficial que podemos encontrar en:\nhttps://docs.kasten.io/latest/multicluster/index.html\nEn este post nos centraremos en las bondades de la nueva solución, próximamente escribiré la guía de instalación que es muy sencilla. Por tanto, una de los requerimientos de k10multicluster es la utilización de Kubernetes contexts, donde en mi caso tengo:\nkubectl config get-contexts Donde puedes mantener la cantidad de cluster que necesites para la administración, por supuesto debe existir comunicación entre todos los Clusters.\nLuego de eso puedes descargar el ejecutable k10multicluster desde\nhttps://github.com/kastenhq/external-tools/releases\nKasten k10 Multi-Cluster utiliza la asignación de clusters Primarios (Primary ) y Secundarios (Secondaries), donde siempre existirá solo 1 primario y los demás que se agreguen serán secundarios, por tanto, debes seleccionar cual será tu cluster primario para luego agregar los secundarios fácilmente. En mi caso usaré el context kubernetes-admin@kubernetes como primario.\nEn la imagen anterior observamos el Dashboard de Multi-Cluster con la configuración del cluster \u0026ldquo;Producción\u0026rdquo; y \u0026ldquo;Desarrollo\u0026rdquo;, aquí es donde revisaremos las opciones más importantes que ofrece esta gran solución.\nRecursos Globales # Una de las grandes ventajas es que nos permite crear recursos para todos los clusters o asignar solo algunos recursos a ciertos clusters, por ejemplo, como ya hemos visto en post anteriores, Kasten k10 siempre necesita \u0026ldquo;Location Profiles\u0026rdquo; o perfiles donde almacenaremos los datos en object storage que puedes usar:\nGoogle Cloud Storage Amazon S3 Azure Storage S3 Compatible Así podrás mantener separados los recursos que necesiten tus distintos Clusters de Kubernetes. Como también Kasten k10 requiere las \u0026ldquo;Policies\u0026rdquo; o Políticas de respaldo las cuales puedes asignar globalmente, aun así cada instalación de Kasten k10 puede tener sus propias políticas si es necesario\nY por ultimo la asignación de \u0026ldquo;Distributions\u0026rdquo; o distribución de los recursos globales que se puedan asignar a cada uno de los clusters o compartir los mismos recursos:\nY aquí en donde ocurre lo importante, por que lo que vimos anteriormente sobre \u0026ldquo;Location Profiles\u0026rdquo; y \u0026ldquo;Policies\u0026rdquo; ya lo hemos usado en las instalaciones normales de Kasten k10, pero en este caso, \u0026ldquo;Distributions\u0026rdquo; aparece para asignar y sincronizar los recursos y políticas a los clusters de Kubernetes que necesitamos realizar la protección de datos, por ejemplo:\nLa distribución \u0026ldquo;wpprd\u0026rdquo; que es para proteger una instancia de wordpress y su respectivo MySQL tiene asignado un bucket en S3 llamado kastenprod con la respectiva política de respaldo y agendamiento de ejecución para el cluster productivo. Inclusive si ingresamos a la isntancia de Kasten k10 de producción podremos ver:\nLa cual no se puede editar directamente desde la instancia productiva, solo se puede editar desde los recursos globales.\nEn un próximo post, explicaré como instalar y configurar paso a paso esta herramienta!\nPosts relacionados # Instalar Kasten Multi-Cluster Manager Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1 Como Instalar Kasten K10 en AWS EKS Kasten K10 Authentik Veeam + Kasten ","date":"17 de noviembre de 2020","externalUrl":null,"permalink":"/es/posts/kasten-k10-multi-cluster/","section":"Blog","summary":"En la ultima versión de Kasten, 3.0.1, podemos encontrar una serie de mejoras y una solución extremadamente importante, la administración centralizada de Múltiples Clusters de Kubernetes para una protección de datos completa, en este post veremos las características y funcionalidades de k10multicluster.","title":"Kasten K10 Multi-Cluster","type":"posts"},{"content":"","date":"17 de noviembre de 2020","externalUrl":null,"permalink":"/es/tags/multicluster/","section":"Etiquetas","summary":"","title":"Multicluster","type":"tags"},{"content":" En este siguiente post, veremos lo fácil que es actualizar Kasten a nuevas versiones para conseguir nuevas características como por supuesto corrección a algunos errores.\nComo siempre, debemos visitar la documentación oficial de la solución para saber las nuevas versiones liberadas y las características que traen, para ello hay que visitar:\nhttps://docs.kasten.io/latest/releasenotes.html\nAhora si no quieres visitar paginas para saber las nuevas versiones, también lo puedes ver en la pagina de configuración de Kasten k10 en el menú de \u0026ldquo;Support\u0026rdquo;\nDonde te indicará si existe una actualización de Kasten k10, solo haces clic en \u0026ldquo;Upgrade to Version\u0026hellip;.\u0026rdquo; y te enviara a la pagina donde se encuentra el comando para actualizar (en mi caso con helm 3):\nhelm repo update \u0026amp;\u0026amp; \\ helm get values k10 --output yaml --namespace=kasten-io \u0026gt; k10_val.yaml \u0026amp;\u0026amp; \\ helm upgrade k10 kasten/k10 --namespace=kasten-io -f k10_val.yaml Antes de ejecutar, siempre es recomendable revisar si existe alguna Política o Job en ejecución para detenerlo o esperar a que finalice para realizar la actualización.\nSi instalaste Kasten k10 en otro namespace, solo debes cambiarlo, luego lo ejecutas:\nLuego de la ejecución del comando, vemos que actualiza los repositorios o charts de helm y actualiza a la nueva versión.\nLuego observaremos que se recrearan algunos Pods de Kasten que aproximadamente se demora unos segundos y podrás ingresar nuevamente al Dashboard de k10, con el siguiente comando podrás ver el estado:\nwatch kubectl -n kasten-io get pods Al ya tener todos los Pods en el estado \u0026ldquo;Running\u0026rdquo; debes ingresar al Dashboard de Kasten k10, luego en \u0026ldquo;Settings\u0026rdquo; y por ultimo en \u0026ldquo;Support\u0026rdquo; para comprobar la versión actualizada:\nAdemás comprobarás que se mantienen todas las estadísticas, políticas y configuraciones que existan en Kasten k10\nCon eso finalizamos, muy simple realizar la actualización!\nPosts relacionados # Como Configurar Repositorio NFS para Kasten K10 Configurar Alertas por Email en Kasten K10 Como Instalar Kasten K10 en AWS EKS Kasten K10 Multi-Cluster Veeam + Kasten ","date":"11 de noviembre de 2020","externalUrl":null,"permalink":"/es/posts/actualizar-kasten-k10/","section":"Blog","summary":"En este siguiente post, veremos lo fácil que es actualizar Kasten a nuevas versiones para conseguir nuevas características como por supuesto corrección a algunos errores.","title":"Actualizar Kasten k10","type":"posts"},{"content":"","date":"11 de noviembre de 2020","externalUrl":null,"permalink":"/es/tags/actualizar-k10/","section":"Etiquetas","summary":"","title":"Actualizar-K10","type":"tags"},{"content":"","date":"11 de noviembre de 2020","externalUrl":null,"permalink":"/es/tags/actualizar-kasten/","section":"Etiquetas","summary":"","title":"Actualizar-Kasten","type":"tags"},{"content":"","date":"11 de noviembre de 2020","externalUrl":null,"permalink":"/es/tags/como-actualizar-kasten/","section":"Etiquetas","summary":"","title":"Como-Actualizar-Kasten","type":"tags"},{"content":"","date":"11 noviembre 2020","externalUrl":null,"permalink":"/en/tags/how-to-upgrade-kasten/","section":"Tags","summary":"","title":"How-to-Upgrade-Kasten","type":"tags"},{"content":"","date":"11 noviembre 2020","externalUrl":null,"permalink":"/en/tags/upgrade-k10/","section":"Tags","summary":"","title":"Upgrade-K10","type":"tags"},{"content":"","date":"11 noviembre 2020","externalUrl":null,"permalink":"/en/tags/upgrade-kasten/","section":"Tags","summary":"","title":"Upgrade-Kasten","type":"tags"},{"content":"","date":"21 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/boostfilesystemstatus/","section":"Etiquetas","summary":"","title":"Boost::Filesystem::Status:","type":"tags"},{"content":"","date":"21 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/error-veeam-oracle/","section":"Etiquetas","summary":"","title":"Error-Veeam-Oracle","type":"tags"},{"content":"","date":"21 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/inventory.xml/","section":"Etiquetas","summary":"","title":"Inventory.Xml","type":"tags"},{"content":"","date":"21 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/orainst.loc/","section":"Etiquetas","summary":"","title":"Orainst.Loc","type":"tags"},{"content":"","date":"21 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/permission-denied/","section":"Etiquetas","summary":"","title":"Permission-Denied","type":"tags"},{"content":" Durante la semana pasada estuve recibiendo algunas consultas sobre algunos errores que se encuentran en los archivos logs de Veeam con la integración de Oracle. Ya sea la integración nativa de Veeam con Oracle sobre VMware o usando Veeam Plugin for Oracle RMAN. En este post veremos como solucionar un error que aparece frecuentemente y es fácil de solucionar.\nIntroducción # El error al cual me refería es el siguiente:\nError has occurred while executing SSH command: boost::filesystem::status: Permission denied: \u0026#34;/grid/app/grid/product/12.2.0.1/oraInst.loc\u0026#34; Error has occurred while executing SSH command: boost::filesystem::status: Permission denied: \u0026#34;/oracle/oraInventory/ContentsXML/inventory.xml\u0026#34; ```bash El error aparece en Veeam Backup \u0026amp; Replication o Veeam Plugin for Oracle RMAN cuando esa tratando de detectar las instancias de Oracle Database que existan en el servidor, como vemos, las soluciones de Veeam no tienen acceso a los archivos. También veremos que el usuario utilizado por Veeam para realizar la consistencia, puede leer directamente los archivos oraInst.loc e inventory.xml desde la linea de comando del sistema operativo. Pero cuando se ejecuta desde las soluciones de Veeam, ya sea el plugin o VBR, sigue sin detectar las instancias y el error aparece nuevamente en los archivos de logs. Para solucionar lo anterior debemos validar los requerimientos de permisos de Veeam Backup \u0026amp; Replication o Veeam Plugin for Oracle, cual sea tu caso: VBR (Bajar hasta los permisos específicos de Oracle): [https://helpcenter.veeam.com/docs/backup/vsphere/required\\_permissions.html?ver=100](https://helpcenter.veeam.com/docs/backup/vsphere/required_permissions.html?ver=100) Veeam Plugin: [https://helpcenter.veeam.com/docs/backup/plugins/rman\\_plugin\\_permissions.html?ver=100](https://helpcenter.veeam.com/docs/backup/plugins/rman_plugin_permissions.html?ver=100) En caso de que el usuario de servicio de veeam (debe poder elevar a root) no se encuentre con los permisos requeridos, será necesario agregarlos a los grupos requeridos, como por ejemplo: ```text usermod -a -G oinstall,dba,grid usuarioveeam ```sql Y por supuesto como también aparece en la documentación, el usuario que se utilice para la autenticación de Oracle debe tener permisos de SYSDBA: Como valido si es usuario que entregaron tiene permisos de SYSDBA?, con el siguiente script de SQL puedes validarlo: ```python select username,sysdba,sysoper,sysasm,sysbackup,sysdg,syskm from v$pwfile_users; ```bash Donde debes validar que el usuario exista en la siguiente salida del comando: De lo contrario, solicitar al DBA que agregue al usuario al rol de SYSDBA. ## Permisos de Oracle Si aun así, aun no consiguen detectar las instancias, la solución pasa por recrear los permisos de las carpetas donde se encuentra instalado Oracle, ya que por algún motivo fueron modificados. Por tanto, en este paso, se debe contar con la ayuda o autorización del DBA para recrear automáticamente los permisos con un script de instalación root.sh o directamente ejecutar lo siguiente en las rutas de Oracle: ```bash chown -R grid:oinstall /u01 chown -R oracle:oinstall /u01/app/oracle chmod -R 775 /u01/ Donde /u01 es la carpeta donde se instalo el software de Oracle y -R quiere decir recursivo. Y con eso funcionará la detección y respaldo de tus bases de datos Oracle en el caso que tengas problemas con permisos de carpeteas y/o archivos.\nPosts relacionados # Veeam Oracle RMAN Plugin Buenas Prácticas Veeam Plugin Oracle RMAN Veeam Explorer Oracle RMAN Veeam Agent Linux - Oracle Linux / Exadata ","date":"21 de octubre de 2020","externalUrl":null,"permalink":"/es/posts/solucion-veeam-oracle-permission-denied/","section":"Blog","summary":"Durante la semana pasada estuve recibiendo algunas consultas sobre algunos errores que se encuentran en los archivos logs de Veeam con la integración de Oracle. Ya sea la integración nativa de Veeam con Oracle sobre VMware o usando Veeam Plugin for Oracle RMAN. En este post veremos como solucionar un error que aparece frecuentemente y es fácil de solucionar.","title":"Solución Veeam Oracle Permission Denied","type":"posts"},{"content":"","date":"8 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/container-backup/","section":"Etiquetas","summary":"","title":"Container-Backup","type":"tags"},{"content":"","date":"8 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/k8s/","section":"Etiquetas","summary":"","title":"K8S","type":"tags"},{"content":"","date":"8 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/respaldo-tkg/","section":"Etiquetas","summary":"","title":"Respaldo-Tkg","type":"tags"},{"content":"","date":"8 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/tanzu-backup/","section":"Etiquetas","summary":"","title":"Tanzu-Backup","type":"tags"},{"content":"","date":"8 octubre 2020","externalUrl":null,"permalink":"/en/tags/tkg-backup/","section":"Tags","summary":"","title":"Tkg-Backup","type":"tags"},{"content":" Excelente noticia! La adquisición de Kasten por Veeam Software, lo cual amplia las bondades de protección de datos de Veeam en los centros de datos modernos con tecnologías de contenedores usando Kubernetes o k8s. En este post veremos la instalación, configuración y recuperación de contendores con Kasten en un cluster de Kubernetes basado en Tanzu Kubernetes Grid.\nIntroducción # Ahora más de alguno/a se preguntará, ¿Qué es Kasten?, Bueno, Kasten es el líder de respaldo y recuperación ante desastres para Kubernetes, una de las características importantes es que es una solución muy fácil de usar, está desarrollada para kubernetes y en una arquitectura nativa para Cloud.\nEs por ello que Kasten puede ayudar a proteger tus contenedores con integración de aplicaciones ya sea en Cloud Publicas o Privadas, por ejemplo, Google Kubernetes Engine, AWS Elastic Kubernetes Services, Azure Kubernetes Services, IBM Kubernetes Services, VMware vSphere, Red Hat OpenShift, entre otros.\nComo también integrarse con distintas tecnologías de Storage, como por ejemplo:\nAmazon Elastic Block Store (EBS) Amazon Elastic File System (EFS) Azure Managed Disks Google Persistent Disk IBM Cloud Block Storage Ceph (RBD) Cinder-based providers on OpenStack vSphere Cloud Native Storage (CNS) (Requiere vSphere 6.7u3+) Portworx Pure Storage Netapp Además permite realizar migraciones de contenedores entre distintos servicios de contenedores para el caso de algún desastre, cambio de proveedor, pruebas o simplemente mantener una arquitectura hibrida.\nSi quieres saber más de Kasten, puedes ingresar a su Web y a la Web de documentación:\nhttps://www.kasten.io/\nhttps://docs.kasten.io/latest/\nLuego de saber un poco que es Kasten, comenzaremos por detallar que tengo como ambiente para respaldar mis contenedores Tanzu Kubernetes Grid 1.1.3, en vSphere 7 Update 1, recuerda que se puede usar desde vSphere 6.7 Update 3\nCluster Productivo de Tanzu Kubernetes Grid: # Donde el management cluster esta con un plan productivo, y para el cluster de aplicaciones también use el plan productivo para utilizar múltiples roles de k8s, si quieres saber mas de los planes que ofrece Tanzu Kubernetes Grid o TKG visita:\nhttps://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.1/vmware-tanzu-kubernetes-grid-11/GUID-tanzu-k8s-clusters-create.html\nY si revisamos los recursos del cluster podremos observar: Con el comando:\nkubectl get pvc,pv,sc --all-namespaces ```bash Nos indicará las solicitudes de discos pvc (PersistentVolumeClaim) para aplicaciones, volúmenes persistentes que son provistos por el sistema o dinámicos pv (PersistenVolume), y la clase de storage o almacenamiento se ofrece al cluster sc (Storage Classes). ```bash kubectl get pod --all-namespaces ```bash Nos indicara todos los pods que instala por defecto Tanzu al crear un cluster y sus respectivos namespaces, que nos permite identificar el proyecto que se instale en el cluster. ```bash kubectl get node --all-namespaces ```text Y por ultimo ver la cantidad de nodos que están involucrados en el cluster y su respectivo rol, como se puede observar en las imagen anterior es posible ver: ```text kube-system vsphere-csi-controller-8c9b98f7f-tt9p6 5/5 Running 8 3h30m kube-system vsphere-csi-node-5k2fp 3/3 Running 0 3h17m kube-system vsphere-csi-node-5skv2 3/3 Running 3 3h11m kube-system vsphere-csi-node-g9dpn 3/3 Running 0 3h17m kube-system vsphere-csi-node-rptch 3/3 Running 3 3h30m kube-system vsphere-csi-node-vgn7s 3/3 Running 3 3h17m kube-system vsphere-csi-node-xg6mb 3/3 Running 3 3h17m ```bash Lo que nos indica que ya se encuentra instalado el driver CSI de vSphere, CSI es el acrónimo de Container Storage Interface: [https://github.com/kubernetes-sigs/vsphere-csi-driver](https://github.com/kubernetes-sigs/vsphere-csi-driver) Este driver es la pieza esencial para la integración de Kubernetes con vSphere ya que permite crear discos para asignarlos a los volúmenes persistentes necesarios para las aplicaciones instaladas en el cluster de Tanzu Kubernetes Grid. ## Storage Class Ahora una de las requerimientos de Kasten son discos persistentes y como vimos anteriormente, el cluster por defecto no posee ningún Storage Class habilitado, por tanto, la aplicación que instalemos no podrá crear los volúmenes que necesite para su funcionamiento, para ello debemos ejecutar en la maquina que esta administrando TKG: ```bash echo \u0026#34; kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: 24xs-vol annotations: storageclass.kubernetes.io/is-default-class: \\\u0026#34;true\\\u0026#34; provisioner: csi.vsphere.vmware.com parameters: DatastoreURL: \u0026#34;ds:///vmfs/volumes/5b00a1aa-6b210381-9411-54e1ad1b3bcd/\u0026#34; fstype: ext4 \u0026#34; \u0026gt; 24xs-vol.yaml kubectl create -f 24xs-vol.yaml ```bash Donde en la linea **5** podemos asignar el nombre del Storage Class, en la linea **7** asegurarnos que el valor sea \u0026#34; **true**\u0026#34; ya que con esto nos aseguramos que quede por defecto configurado y habilitado, linea **8** nos aseguramos que es el driver csi de vsphere, en la linea **10** es clave para indicarle la url del Datastore que utilizaremos como destino de los volúmenes persistentes en vSphere (en la siguiente imagen veras de donde tomar el dato) y por ultimo el nombre del archivo para guardarlo con su extensión .yaml. Como observamos en la imagen anterior el primer comando nos muestra que no tenemos ningún Storage Class en nuestro cluster de Tanzu y luego ejecutamos el archivo para generar el Storage Class que podemos ver con el comando: ```bash kubectl get sc ```bash Ahora, si revisamos el monitoreo del DataStore que seleccionamos para ser el almacenamiento de nuestros volúmenes persistentes, veremos lo siguiente en vCenter: Por tanto ya tenemos todo listo para instalar Kasten k10 en su ultima versión 2.5.22. ## Instalación de Kasten Ahora revisaremos los prerrequisitos de Kasten que los puedes encontrar: [https://docs.kasten.io/latest/install/requirements.html](https://docs.kasten.io/latest/install/requirements.html) Lo primero que necesita es instalar helm, que es una administrador de paquetes para instalar fácilmente aplicaciones: [https://helm.sh/](https://helm.sh/) La instalación de helm es muy sencilla solo debemos descargar el archivo desde github y moverlo a la carpeta de ejecutables del servidor que estas usando para administrar Tanzu Kubernetes Grid o TKG: ```bash wget https://get.helm.sh/helm-v3.3.4-linux-amd64.tar.gz ```json ```bash tar xvzf helm-v3.3.4-linux-amd64.tar.gz ```json ```text cd linux-amd64/ ```bash Y por ultimo lo movemos a la carpeta de ejecutables: ```bash mv helm /usr/local/bin/ ```bash si ejecutamos el comando helm versión veremos la versión de helm: Como indica el manual de Kasten, lo que debemos realizar ahora es agregar el repositorio de Kasten en helm, con el siguiente comando: ```bash helm repo add kasten https://charts.kasten.io/ ```bash Y luego crear el nombre del proyecto o namespace con el comando: ```bash kubectl create namespace kasten-io ```bash Luego procederemos a la instalación como se indica en: [https://docs.kasten.io/latest/install/vmware/vsphere.html](https://docs.kasten.io/latest/install/vmware/vsphere.html) El primer comando a ejecutar es: ```bash helm install k10 kasten/k10 --namespace=kasten-io ```bash Los cual nos mostrará: Y luego con el siguiente comando podremos ver el progreso de instalación: ```bash kubectl get pods --namespace kasten-io --watch ```bash Y podremos ver: Debemos asegurarnos que todos los pods se encuentren en estado \u0026#34; **Running**\u0026#34; ya que con esto luego podremos acceder a la consola de Kasten. Si revisamos nuestro Datastore que anteriormente no almacenaba volúmenes persistentes y actualizamos podremos observar: Nos listará los volúmenes usados por Kasten para su correcto funcionamiento. Y volvemos a asegurarnos que todos los pods estén en su estado \u0026#34;Running\u0026#34;: Y ya tenemos instalado Kasten! ## Acceder a Kasten Como vimos en una imagen anterior, Kasten nos indico que para acceder al Dashboard necesitamos ingresar un comando: ```bash kubectl --namespace kasten-io port-forward service/gateway 8080:8000 ```text Y luego ingresar a la url: ```text http://127.0.0.1:8080/k10/#/. ```bash Y obviamente si es que tienes instalado GUI o Desktop en tu linux de administración de Tanzu Kubernetes Grid podrás acceder. Pero que pasa si no tengo instalado GUI y necesito acceder desde la red via Web? Existen distintas formas de acceder al Dashboard de Kasten, aquí veremos la mas simple y rápida con autenticación que inclusive también lo puedes encontrar en el manual de Kasten, de hecho revisaremos los siguientes links: [https://docs.kasten.io/latest/access/dashboard.html#dashboard](https://docs.kasten.io/latest/access/dashboard.html#dashboard) [https://docs.kasten.io/latest/access/authentication.html#basic-auth](https://docs.kasten.io/latest/access/authentication.html#basic-auth) ```bash https://hostingcanada.org/htpasswd-generator/ ```bash El primer link nos dice las múltiples formas de ingresar al Dashboard, en este caso utilizaremos \u0026#34; **Accessing via a LoadBalancer**\u0026#34;, para ello instalaremos \u0026#34;metallb\u0026#34; que es un balanceador para k8s: [https://metallb.universe.tf/](https://metallb.universe.tf/) La instalación es muy sencilla, debemos ejecutar el siguiente comando: ```bash kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.3/manifests/metallb.yaml ```bash Y ya está instalado. Ahora lo configuraremos con el rango de direcciones IP que deseamos que trabaje: ```bash cat \u0026lt;\u0026lt;EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | address-pools: - name: default protocol: layer2 # MetalLB IP Pool addresses: - 20.20.20.110-20.20.20.140 EOF ```bash En la linea **15**, debemos ingresar un pool de direcciones IP para que las asigne a los servicios que instalemos. Y ejecutamos: Luego de esto volvemos a la configuración de Kasten, debemos generar una contraseña htpasswd, en los links anteriores aparece una web que nos permite realizarlo online: Copiamos el usuario y contraseña y lo agregamos en el siguiente comando (Si copian y pegan la contraseña cifrada es 24xsiempre.com): ```bash helm upgrade k10 kasten/k10 --namespace=kasten-io \\ --set auth.basicAuth.enabled=true \\ --set auth.basicAuth.htpasswd=\u0026#39;admin:$apr1$8zsf2361$V3BlxNRZsfbnUmDFM.XRa1\u0026#39; ```bash En la linea **3**, debes copiar tu usuario y password generado en la web. Luego ejecutamos: Con el comando anterior solo configuramos el mecanismo de autenticación, ahora con la siguiente instrucción le indicaremos que nos permita acceder a través del gateway de Kasten y el balanceador: ```bash helm upgrade k10 kasten/k10 --namespace=kasten-io \\ --reuse-values \\ --set externalGateway.create=true ```bash Vimos que el mensaje cambió y Kasten ahora nos indico que debemos acceder al Dashboard vía: ```bash The K10 Dashboard is accessible via a LoadBalancer. Find the service\u0026#39;s EXTERNAL IP using: `kubectl get svc gateway-ext --namespace kasten-io -o wide` And use it in following URL `http://SERVICE_EXTERNAL_IP/k10/#/` ```bash Por tanto, solo nos queda saber la dirección IP para acceder, la cual la obtendremos con el siguiente comando: ```bash kubectl get svc gateway-ext --namespace kasten-io -o wide **Cabe señalar que tengo habilitado DHCP en TKG**\nEn mi caso la url de acceso será http://kastentkg.24xsiempre.cl/k10/#/ ya que la dirección IP la asocie al DNS (Si no accede directamente a la IP de EXTERNAL-IP) y solicitará el usuario y contraseña antes configurado a través de la pagina que genera el htpasswd: Y veremos la pantalla de Bienvenida de Kasten, ingresamos empresa, correo y aceptamos: Configuración de Kasten # Ya tenemos funcionando Kasten, con posibilidad de acceder remotamente con usuario y contraseña, ahora solo nos falta habilitar y configurar la solución, en la parte inferior del Dashboard aparece un mensaje importante \u0026quot; K10 Disaster Recovery is not enabled for this cluster. \u0026quot; Hacemos clic en \u0026quot; See Settings\u0026quot; donde nos indicara que debemos realizar algunas configuraciones antes de Habilitar Kasten: Hacemos clic en \u0026quot; Locations\u0026quot; y crearemos un nuevo perfil, en este caso Amazon s3: Como se observa, podrás utilizar distintos perfiles para almacenar los Containers los que pueden ser:\nGoogle Cloud Storage Amazon S3 Azure Storage S3 Compatible Ingresas los datos solicitados y veremos el perfil creado: Luego clic en \u0026quot; Infrastructure\u0026quot; y generaremos un perfil para vSphere: Al igual que el perfil anterior, tenemos distintas opciones:\nOpenStack Ceph Portworx vSphere Ahora volvemos a hacer clic en \u0026quot; K10 Disaster Recovery\u0026quot; y procederemos a habilitar Kasten haciendo clic en \u0026quot; Enable K10 DR\u0026quot;, seleccionamos el perfil de \u0026quot; Location\u0026quot; y asignamos una contraseña para cifrar los respaldos. Muy importante Guarda la contraseña ya que la necesitaras en algunas recuperaciones Y después si Quieres cambias el tema del Dashboard en el menú \u0026ldquo;Dashboard\u0026rdquo; y volvemos al inicio para configurar Políticas de respaldo: Paralelamente instalé un wordpress en su propio namespace para ver los respaldos de una aplicación adicional: Al crear un nuevo namespace, Kasten lo reconocerá automáticamente en la parte de \u0026quot; Applications\u0026quot; e indicará que se encuentra \u0026quot; Unmanaged\u0026quot; ya que no tiene ninguna política de respaldo asociada: Puedes lanzar un \u0026quot; Snapshot\u0026quot; directamente desde \u0026quot; Applications\u0026quot;, realizar tareas de restauración o \u0026quot; Export\u0026quot; el Container que desees.\nPolíticas de Respaldos # Ingresaremos a \u0026quot; Policies\u0026quot; y veremos una política por defecto de Kasten para protegerse a sí mismo: El cual, como recomendación, no debemos cambiar ya que estará ejecutándose con su respectiva política de retención. Ahora haremos clic en \u0026quot; Create New Policy\u0026quot; e ingresaremos los datos solicitados: Donde ingresamos el nombre, comentarios y la acción, para el caso de protección de datos necesitamos seleccionar \u0026quot; Snapshot\u0026quot; y seleccionar la frecuencia de los snapshots y su respectiva retención. Si haces clic en \u0026quot; Show Advanced Frequency Options\u0026quot; podrás seleccionar la hora de ejecución: Luego si lo deseamos, podemos exportar los respaldos hacia el bucket S3 habilitando \u0026quot; Backups via Snapshot Exports\u0026quot;: Luego seleccionaremos la aplicación a respaldar, buscándola por \u0026quot; Name\u0026quot; o si quieres por \u0026quot; Label\u0026quot; en este caso seleccionare wordpress Y por ultimo hacemos clic en \u0026quot; Create Policy\u0026quot; Ahora podemos ejecutar el respaldo directamente o esperar la agenda. Lo ejecutare para ver el respaldo haciendo clic en \u0026quot; Run once\u0026quot; Y volveremos al Dashboard para ver el estado del respaldo: Además veremos las ejecuciones de snapshots en vCenter: También veremos todas las ejecuciones que configuramos en la política: Y ya estamos respaldando nuestro Tanzu Kubernetes Grid con Kasten!\nRecuperación Containers con Kasten # Si hacemos clic en \u0026quot; Applications\u0026quot; veremos nuestra política de respaldo exitosa para wordpress: En la parte inferior de la política podrás ver un botón \u0026quot; Restore\u0026quot; nos mostrara los puntos de restauración que tenemos: Y si hacemos clic en el punto de restauración: Nos permitirá elegir desde donde deseas recuperar, ya sea desde s3 o del snapshot local, en este caso seleccionare el local: Para confirmar: Y por ultimo volvemos al Dashboard para ver el estado: Y podremos ver la recuperación exitosa: Existen múltiples opciones de recuperación que se deben analizar de acuerdo a la necesidad, pero como vimos el respaldo es simple, la detección de los namespaces lo hace automáticamente y es muy fácil configurar políticas de respaldos, en el siguiente link tienes el detalle de todas las opciones de recuperación:\nhttps://docs.kasten.io/latest/usage/restore.html\nY con eso finalizamos esta guía para usar Kasten! Cualquier idea es bienvenida como siempre!\nPosts relacionados # Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1 Red Hat OpenShift en vSphere con Kasten Como Instalar Kasten K10 en AWS EKS Kasten K10 Multi-Cluster Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam ","date":"8 de octubre de 2020","externalUrl":null,"permalink":"/es/posts/veeam-kasten/","section":"Blog","summary":"Excelente noticia! La adquisición de Kasten por Veeam Software, lo cual amplia las bondades de protección de datos de Veeam en los centros de datos modernos con tecnologías de contenedores usando Kubernetes o k8s. En este post veremos la instalación, configuración y recuperación de contendores con Kasten en un cluster de Kubernetes basado en Tanzu Kubernetes Grid.","title":"Veeam + Kasten","type":"posts"},{"content":"","date":"6 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/agendar-respaldos/","section":"Etiquetas","summary":"","title":"Agendar-Respaldos","type":"tags"},{"content":"","date":"6 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/cockpit/","section":"Etiquetas","summary":"","title":"Cockpit","type":"tags"},{"content":"","date":"6 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/respaldo-sap-hana/","section":"Etiquetas","summary":"","title":"Respaldo-Sap-Hana","type":"tags"},{"content":"","date":"6 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/sap-hana/","section":"Etiquetas","summary":"","title":"Sap-Hana","type":"tags"},{"content":"","date":"6 octubre 2020","externalUrl":null,"permalink":"/en/tags/sap-hana-backup/","section":"Tags","summary":"","title":"Sap-Hana-Backup","type":"tags"},{"content":" Ahora es el turno de otro de los plugins, Veeam for SAP HANA, donde es muy simple implementarlo como también realizar las configuraciones en SAP HANA, en este post, veremos la instalación, configuración, agendamiento de respaldos desde SAP HANA y por supuesto la recuperación de datos.\nPasos Iniciales # Primero, como siempre, debemos revisar la documentación oficial de Veeam Plugin for SAP HANA para validar las versiones soportadas:\nhttps://helpcenter.veeam.com/docs/backup/plugins/system_requirements_saphana.html?ver=100\nYa sabemos que nuestro SAP HANA tiene soporte desde Veeam para realizar los respaldos a través del Plugin, él cual, es una interfaz \u0026ldquo;Backint\u0026rdquo; ya que necesita certificación del fabricante, en este caso SAP HANA, para el correcto funcionamiento, para validar la certificación la podemos ver en:\nhttps://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=451067853\nInstalación # Ahora que ya sabemos todos los datos anteriores, necesitamos realizar la instalación del plugin en el servidor de SAP HANA, montaremos la ISO de Veeam Backup \u0026amp; Replication v10a y copiaremos el plugin VeeamPluginforSAPHANA-10.0.1.4854-1.x86_64.rpm, por ejemplo con WinSCP:\nLuego de eso ingresamos vía SSH al servidor, ya sea con el usuario \u0026ldquo;root\u0026rdquo; o con el usuario de la aplicación que posea permisos de sudo, en mi caso, utilizare \u0026ldquo;hxeadm\u0026rdquo;.\nSiempre recordar que los plugins de Veeam se instalan con root y se configuran con el usuario de la aplicación.\nPor tanto instalaremos el plugin con el siguiente comando:\nsudo rpm -ivh VeeamPluginforSAPHANA-10.0.1.4854-1.x86_64.rpm ```json ## Configuración Luego de instalar, el plugin de Veeam para SAP HANA nos indicará que debemos realizar el comando: ```text Run \u0026#34;SapBackintConfigTool --wizard\u0026#34; to configure the Veeam Plug-in for SAP HANA ```bash Aquí ejecutaremos el comando que se nos indico sin sudo y con el usuario de aplicación, en mi caso hxeadm e ingresamos los parámetros que nos solicita: Como se ve en la imagen anterior, solo nos pide los datos de nuestro Veeam Backup \u0026amp; Replication y el repositorio que utilizaremos para respaldar. Recuerda que si no aparece un repositorio, debes darle acceso en las propiedades del repositorio en el menú \u0026#34;Access Permissions\u0026#34;: Ya tenemos configurado el plugin en el servidor de SAP HANA, para validar la configuración debemos revisar el menú de backup en SAP HANA Studio por ejemplo: Donde veremos: ```text Backint Agent: /opt/veeam/VeeamPluginforSAPHANA/hdbbackint Que es la ruta donde se alojan los archivos de configuración y la interfaz Backint. En la parte de \u0026ldquo;Log Backup Settings\u0026rdquo; es recomendable configurarlos con \u0026ldquo;Backint\u0026rdquo; en vez de \u0026ldquo;File\u0026rdquo;, ya que estaremos llevamos los respaldos y los logs de la base de datos al repositorio de Veeam.\nSolo nos queda realizar el respaldo de SAP HANA desde SAP HANA Studio, ya que es la forma y el como deben realizarse los respaldos para mantener el soporte de SAP.\nSeleccionamos la base de datos que deseamos respaldar y luego le indicamos el tipo de respaldo que necesitamos, Completo, Diferencial o Incremental y por supuesto el tipo de destino que debe ser backint:\nLuego hacemos clic en \u0026ldquo;Next\u0026rdquo; y \u0026ldquo;Finish\u0026rdquo; para observar el estado del respaldo, también lo podremos observar en Veeam Backup \u0026amp; Replication:\nY rápidamente ya tenemos respaldando SAP HANA en los repositorio de Veeam a través de Veeam Plugin for SAP HANA.\nAgendamiento # Aquí entramos en la pregunta que siempre nos hacen:\n¿Cómo se realiza el Agendamiento del Respaldo de SAP HANA?\nPara resolver la pregunta existen múltiples formas de realizar el agendamiento de los respaldos, por ejemplo:\nAgenda / Schedule de Veeam Agent for Linux Control-M Propias del Sistema Operativo SAP HANA Cockpit Muchas más\u0026hellip; Por tanto, como mencioné anteriormente hay varias formas de agendar la ejecución de respaldos de SAP HANA utilizando Veeam Plugin for SAP HANA, una de las más utilizadas es integrarlo con Veeam Agent for Linux para realizar respaldo de archivos de configuración de SAP HANA y ejecutar el script de respaldo, configurándolo en conjunto con un grupo de protección como lo vimos en el post de Veeam Oracle Linux:\nhttps://www.24xsiempre.com/veeam-agent-linux-oracle-linux-exadata/\nAhora vamos a ver otra forma de agendar los respaldos, directamente desde SAP HANA, utilizando la herramienta SAP HANA Cockpit, pero antes de agendar respaldos vamos a ver algunas configuraciones avanzadas de SAP Hana para el respaldo. En la configuración de SAP HANA en la parte de Backup, es posible cambiar las siguientes variables:\ndata_backup_buffer_size parallel_data_backup_backint_channels Las cuales permitirán realizar el respaldo por múltiples streams con el buffer de memoria que indica la buena practica desde SAP HANA, asegúrate de contar con recursos de memoria, si deseas revisar los parámetros en los siguientes links de SAP tienes la información:\nhttps://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.04/en-US/5c6a0d4a81db4eebba7f5b2620d53a63.html?q=data_backup_buffer_size\nhttps://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.04/en-US/18db704959a24809be8d01cc0a409681.html\nEn este caso hemos ingresado 4 streams, 2048 MB de buffer (512MB por cada stream):\nEs muy importante revisar estos puntos con el DBA de SAP HANA o con tu partner de tecnología, ya que son configuraciones del sistema y necesitan ser validadas, aun así, en este post estamos utilizando información directamente desde el manual de SAP HANA, además si quieres agregar funciones avanzadas o respaldar el catalogo también es necesario involucrar al DBA.\nAhora volveremos a SAP HANA Cockpit ( link), donde nos permitirá realizar respaldos nativamente integrados con Veeam Plugin for SAP HANA, para acceder a la web de SAP HANA Cockpit en mi caso la dirección es https://hxehost:51045/cockpit#Shell-home:\nAl ingresar a la instancia que deseemos respaldar veremos un widget para respaldos:\nSi hacemos clic en \u0026ldquo;Backup Schedules\u0026rdquo; podremos ingresar a la configuración de Respaldos de SAP HANA y ver un resumen de los tipos de respaldo realizado o por realizar. Luego hacemos clic en el icono \u0026quot; +\u0026quot; para agregar un agendamiento de respaldo:\nY seleccionaremos \u0026ldquo;Schedule a Series of Backups\u0026rdquo; para pasar al Paso 2 e ingresar el nombre del respaldo:\nAl pasar a el paso 3 \u0026ldquo;Backup Settings\u0026rdquo; debemos configurar el tipo de respaldo:\nY en \u0026ldquo;Backup Settings\u0026rdquo; la configuración importante es el tipo de respaldo y que utilizaremos \u0026ldquo;Backint\u0026rdquo; para llevar nuestros respaldos al repositorio de Veeam Backup \u0026amp; Replication a través de Veeam Plugin for SAP HANA. Luego seleccionaremos las veces que ejecutaremos el respaldo:\nY por ultimo en que horario y días necesitamos que se ejecute el respaldo:\nIngresamos la zona horaria, hora de ejecución del respaldo, días de ejecución y por ultimo cuando activar la ejecución de la tarea de respaldo. Por ultimo guardamos los cambios con \u0026ldquo;Save Schedule\u0026rdquo;\nVolveremos a la pagina inicial donde aparecerá la agenda:\nEn el horario que configuramos se ejecutará:\nTambién veremos la ejecución de la tarea en Veeam Backup \u0026amp; Replication\nEn SAP HANA Studio también podemos ver los respaldos realizados:\nPor tanto ahora veremos la recuperación, puedes realizarlo tanto de SAP HANA Cockpit o desde SAP HANA STUDIO, en este caso utilizaremos la forma tradicional de recuperar una base de datos desde SAP HANA Studio desde los respaldos en Veeam Backup \u0026amp; Replication:\nRecuperación # Y como vimos en las imágenes anteriores, ya podemos recuperar bases de datos de SAP HANA Studio fácilmente, vamos a la consola y seleccionamos lo siguiente:\nLuego SAP HANA nos indica para recuperar bases de datos en este caso SYSTEM los servicios deben estar detenidos:\nEsperamos que los servicios se detengan:\nY luego podremos realizar la recuperación de la base de datos por ejemplo al estado mas reciente:\nRealizamos siguiente y cuando lleguemos a la siguiente pantalla, seleccionas un respaldo y clic en \u0026ldquo;Check Availability\u0026rdquo;:\nLuego seguir hasta el final:\nY hacer clic en \u0026ldquo;Finish\u0026rdquo; para esperar la recuperación:\nY veremos también la recuperación como tarea en ejecución en Veeam Backup \u0026amp; Replication\nCon eso finalizamos el post sobre Veeam Plugin for SAP HANA para proteger tus ambientes y utilizando herramientas existentes en la solución. Todas las sugerencias son bienvenidas!\nPosts relacionados # Veeam Oracle RMAN Plugin Veeam Agent Linux - Oracle Linux / Exadata Veeam Hardened (Immutable) Repository Veeam Agent para Solaris y Veeam 11a ","date":"6 de octubre de 2020","externalUrl":null,"permalink":"/es/posts/veeam-plugin-sap-hana-cockpit/","section":"Blog","summary":"Ahora es el turno de otro de los plugins, Veeam for SAP HANA, donde es muy simple implementarlo como también realizar las configuraciones en SAP HANA, en este post, veremos la instalación, configuración, agendamiento de respaldos desde SAP HANA y por supuesto la recuperación de datos.","title":"Veeam Plugin SAP HANA","type":"posts"},{"content":"","date":"6 de octubre de 2020","externalUrl":null,"permalink":"/es/tags/veeam-plugin-sap-hana/","section":"Etiquetas","summary":"","title":"Veeam-Plugin-Sap-Hana","type":"tags"},{"content":"","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/dkms/","section":"Etiquetas","summary":"","title":"Dkms","type":"tags"},{"content":"","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/exadata/","section":"Etiquetas","summary":"","title":"Exadata","type":"tags"},{"content":"","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/instalacion-veeam-agent-linux-oracle/","section":"Etiquetas","summary":"","title":"Instalacion-Veeam-Agent-Linux-Oracle","type":"tags"},{"content":"","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/kernel-uek/","section":"Etiquetas","summary":"","title":"Kernel-Uek","type":"tags"},{"content":"","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/oracle-linux/","section":"Etiquetas","summary":"","title":"Oracle-Linux","type":"tags"},{"content":"","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/oracle-uek/","section":"Etiquetas","summary":"","title":"Oracle-Uek","type":"tags"},{"content":"","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/snapshotless/","section":"Etiquetas","summary":"","title":"Snapshotless","type":"tags"},{"content":" Y ya que hemos revisado respaldo de bases de datos Oracle, integración con Oracle Cloud utilizando Object Storage, ahora nos falta ver la protección de datos con Veeam Agent for Linux, para la protección de los sistemas operativos Oracle Linux, Appliances Exadata, carpetas o algún dato importante de los sistemas a proteger como también revisar la forma de instalación en un Kernel UEK vs un Kernel RedHat y por supuesto instalar versiones y dependencias de Kernel con las mismas versiones que necesita Veeam Agent for Linux.\nIntroducción # Por lo general es una de las consultas que siempre estoy respondiendo, ya que técnicamente son muy parecidas las versiones de Oracle Linux y Redhat, pero en particular, Oracle posee su propia versión de Kernel, conocida como UEK (Unbreakable Enterprise Kernel) y en el siguiente link podrás ver todas las versiones desde cuando fueron lanzadas como también las ultimas lanzadas:\nhttps://blogs.oracle.com/scoter/oracle-linux-and-unbreakable-enterprise-kernel-uek-releases\nAdemás muchas empresas ya tienen o están pensando en adquirir Oracle Exadata que es un Appliance optimizado para el servicio de base de datos con integración a Cloud publica de Oracle (no entraré en detalles ya que hay mucha información en internet) el cual en su versión x86 esta basado en Oracle Enterprise Linux, por tanto, va a ser posible protegerlos con Veeam Agent for Linux, he visto Exadata con diferentes versiones de Oracle Linux, por ejemplo desde la versión 6 de OEL hasta versiones de OEL 7.7. En los últimos releases de Exadata están incluyendo la versión de OEL 7.7 UEK5 como se indica en la documentación:\nhttps://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmso/new-features-exadata-system-software-release-19.html#GUID-3B6B74A6-F225-4BD7-813D-BDC6053CE122\nYa que vimos información sobre Oracle Linux y Exadata, veremos también los sistemas operativos soportados por Veeam para realizar respaldos en estos sistemas, que para el caso de Oracle Linux, tiene soporte para:\nOracle Linux 6 – 8.2 (RHCK)3 Oracle Linux 6 (starting from UEK R1) – Oracle Linux 8.0 (up to UEK R6)3 Donde por supuesto pueden ver más información actualizada en el manual de Veeam Agent for Linux:\nhttps://helpcenter.veeam.com/docs/agentforlinux/userguide/system_requirements.html?ver=40\nConfiguración # Ahora, ya que sabemos que tenemos soporte de Veeam Agent for Linux para respaldar éstas hermosas soluciones, procederemos a lo importante, instalar las dependencias que exige Veeam Agent for Linux, pero antes, debemos saber que versión de Kernel y sistema vamos a proteger, en mi caso:\nDe la imagen anterior podemos ver que tenemos un Oracle Linux 7.7 y su respectivo kernel 4.14.35-2025.400.9.el7uek.x86_64, entonces volveremos a las dependencias de Veeam Agent for Linux, que exige:\ndkms kernel-uek-devel Y la versión del Kernel o mejor dicho Kernel UEK necesita la instalación de los paquetes anteriores para funcionar con Veeam Agent for Linux, pero si fuese un Kernel Redhat, solo necesitaría instalar Kernel-headers en la misma versión del Kernel actual ya que veeam utiliza kmod-veeamsnap. Como siempre, en este caso, nos encontraremos con el Kernel-UEK debemos instalar los paquetes que mencione con el comando:\nyum install kernel-uek-devel-$(uname -r)\nAl ingresar \u0026ldquo;Y\u0026rdquo; ya instalará todos los paquetes y sus dependencias para finalizar:\nPor tanto ya tenemos un paquete instalado, ahora nos falta instalar DKMS, que significa Dynamic Kernel Module Support y nos ayudara a utilizar paquetes de veeam (veeamsnap en si) a nivel de kernel, debemos asegurarnos que la versión del kernel-uek y la versión del kernel-uek-devel deben ser exactamente la misma versión:\nAhora que tenemos certeza de las versiones procederemos a instalar DKMS, con el comando:\nyum install dkms\nAl hacer el comando anterior nos devolverá un error:\nEste error nos aparece ya que no tenemos habilitado/instalado el repositorio EPEL (Extra Packages for Enterprise Linux) de Oracle Linux, por tanto procederemos a instalarlo. Debemos entrar a la carpeta:\ncd /etc/yum.repos.d/ vi epel.repo ```text Y luego escribir / pegar: ```ini [ol7_epel] name=Oracle Linux $releasever EPEL ($basearch) baseurl=http://yum.oracle.com/repo/OracleLinux/OL7/developer_EPEL/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 enabled=1 Con lo anterior volvemos a ejecutar el comando para instalar dkms y sus dependencias:\nyum install dkms\nVeeam Backup \u0026amp; Replication # Ya con eso tenemos las dependencias requeridas por Veeam Agent for Linux para Oracle Linux o Exadata que mantengan la versión soportada y ahora es solo cosa de agregarlas a un grupo de protección de Veeam Backup \u0026amp; Replication:\nDonde en la imagen anterior ven la creación de un grupo de protección y luego al hacer clic en \u0026ldquo;FINISH\u0026rdquo;, veremos la instalación automatizada de Veeam Agent for Linux desde la consola de Veeam Backup \u0026amp; Replication (Si necesitas instalarlo manualmente es cosa que descargues los paquetes de veeam.com y los instales directamente en el servidor):\nYa con esto estamos preparados para realizar el respaldo de nuestro Oracle Linux o Exadata a nivel de archivos / filesystem e integrarlo con Veeam Plugin for Oracle RMAN que lo pueden leer en este link:\nhttps://www.24xsiempre.com/veeam-oracle-rman-plugin/\nComo configurar Veeam Plugin for Oracle RMAN\nUna buena recomendación que les haré, es que cuando configuren el Job o tarea de respaldo con el Veeam Agent for Linux sobre un Oracle Database, Oracle RAC u Oracle Exadata, es que utilicen la opción de File Level Backup y Snapshotless backup para proteger solo las carpetas que necesitan respaldar y agregando Veeam Plugin for Oracle RMAN:\nY lo demás es historia conocida, para la configuración de tareas / jobs de respaldo.\nPosts relacionados # Veeam Oracle RMAN Plugin Buenas Prácticas Veeam Plugin Oracle RMAN Veeam Explorer Oracle RMAN Protegiendo Oracle KVM con Veeam ","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/posts/veeam-agent-linux-oracle-linux-exadata/","section":"Blog","summary":"Y ya que hemos revisado respaldo de bases de datos Oracle, integración con Oracle Cloud utilizando Object Storage, ahora nos falta ver la protección de datos con Veeam Agent for Linux, para la protección de los sistemas operativos Oracle Linux, Appliances Exadata, carpetas o algún dato importante de los sistemas a proteger como también revisar la forma de instalación en un Kernel UEK vs un Kernel RedHat y por supuesto instalar versiones y dependencias de Kernel con las mismas versiones que necesita Veeam Agent for Linux.","title":"Veeam Agent Linux - Oracle Linux / Exadata","type":"posts"},{"content":"","date":"29 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/veeam-exadata/","section":"Etiquetas","summary":"","title":"Veeam-Exadata","type":"tags"},{"content":"","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/categories/capacity-tier/","section":"Categorías","summary":"","title":"Capacity-Tier","type":"categories"},{"content":"","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/oracle-cloud/","section":"Etiquetas","summary":"","title":"Oracle-Cloud","type":"tags"},{"content":"","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/oracle-cloud-object-storage/","section":"Etiquetas","summary":"","title":"Oracle-Cloud-Object-Storage","type":"tags"},{"content":"","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/s3-compatible/","section":"Etiquetas","summary":"","title":"S3-Compatible","type":"tags"},{"content":"","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/scale-out-backup/","section":"Etiquetas","summary":"","title":"Scale-Out-Backup","type":"tags"},{"content":" Últimamente algunas personas me han preguntado si Veeam posee soporte o funciona con el servicio de Object Storage de Oracle Cloud, para configurarlo en Veeam Capacity Tier y ya que en el anterior post hablamos sobre Oracle, en este post veremos como integrar el servicio de Oracle Cloud Object Storage con un Veeam Scale-Out Backup Repository o SOBR y demostrar las ventajas de poseer una solución con movilidad multicloud.\nIntroducción # Para saber más sobre Veeam Capacity Tier, configuraciones, requerimientos, etc. (Ya que en esta guía no entraremos en detalles de Capacity Tier), debemos revisar la documentación oficial para observar los servicios soportados:\nhttps://helpcenter.veeam.com/docs/backup/vsphere/capacity_tier.html?ver=100\nComo se ve en el link anterior, vemos que no existe \u0026ldquo;soporte directo\u0026rdquo; para trabajar con Object Storage de Oracle Cloud, pero sí, tenemos una opción que aparece como \u0026ldquo;S3-compatible object storage repository\u0026rdquo; el cual debemos confirmar si es posible agregarlo por esta vía.\nEs por eso que en los foros de Veeam ( Foros de Veeam, Regístrense) existe una lista \u0026ldquo;No Oficial\u0026rdquo; donde podrás encontrar todos los proveedores de Object Storage que tienen compatibilidad, soporte para inmutabilidad y por supuesto siempre se va actualizando:\nhttps://forums.veeam.com/object-storage-f52/unoffizial-compatibility-list-for-veeam-cloud-tier-t56956.html\nEn el link anterior encontraremos como \u0026ldquo;Compatible\u0026rdquo; Oracle Cloud Object Storage (Cloud Object Storage) NEW, lo que nos permite saber que existe compatibilidad entre las dos soluciones, por tanto, configuremos! Es muy importante validar con soporte de Veeam si necesitas una garantía de funcionamiento.\nCreación de Bucket # Ya con nuestra cuenta de Oracle Cloud (Para pruebas pueden usar el Modo Gratuito de Oracle Cloud que provee 10GB de espacio en Object Storage), debemos crear las credenciales de acceso a a los servicios de Oracle Cloud, para esto, dentro de la consola de Oracle Cloud, ingresaremos a Identity \u0026gt; Users:\nOracle Cloud Users Luego crearemos un usuario presionando \u0026ldquo;Create User\u0026rdquo; seleccionando el modo IAM, luego ingresar el nombre de usuario, descripción y correo si lo tiene, para finalmente ver el usuario creado y sus detalles:\nAgregamos al usuario al Grupo de Administradores:\nLuego crearemos las \u0026ldquo;Customer Secret Keys\u0026rdquo; para poder autenticarnos al servicio de Object Storage en Oracle Cloud, haciendo clic en \u0026ldquo;Generate Secret Key\u0026rdquo;, ingresamos el nombre de la clave y luego copiamos la key generada:\nY podremos observar la nueva llave en la tabla de Customer Secret Keys:\nAhora dentro de la Consola de Oracle Cloud, debemos ir a la administración de Object Storage y podrás ver:\nDonde realizaremos la creación del Bucket que almacenarás los respaldos enviados a través de Capacity Tier de Veeam, para ello, debes hacer clic en \u0026ldquo;Create Bucket\u0026rdquo; e ingresar un nombre único, seleccionando lo siguiente:\nAl generar el bucket de acuerdo a las configuraciones anteriores, nos listará el bucket creado con el nombre que ingresamos:\nAhora ya tenemos la creado el bucket del Object Storage en Oracle Cloud y debemos comenzar con la configuración de Veeam Backup \u0026amp; Replication.\nConfiguración SOBR Veeam Backup # Como ya sabemos que el servicio de Object Storage en Oracle Cloud es compatible con Veeam Backup \u0026amp; Replication, por que visitamos los foros de Veeam confirmando la compatibilidad, solo nos queda realizar la configuración que es muy sencilla de realizar, agregaremos un repositorio Object Storage que sea S3 Compatible:\nLuego ingresaremos el nombre del Repositorio, hacemos clic en Next y aquí viene la parte interesante, donde debemos ingresar el Service Point, Región y las credenciales que antes generamos en \u0026ldquo;Customer Secret Keys\u0026rdquo;\nAquí les explicaré algo muy importante, para saber los datos anteriores, ya que primero necesitamos saber la URL del Service Point, que tiene la siguiente nomenclatura:\n\u0026lt;object-storage-namespace\u0026gt;.compat.objectstorage.\u0026lt;region\u0026gt;.oraclecloud.com ```text Donde lo primero que necesito buscar es el \u0026lt;object-storage-namespace\u0026gt; ya que la región siempre la sabremos al ver nuestra consola de Oracle Cloud, para saber este dato, necesitamos ir a al menú de nuestro Tenant y hacer clic en \u0026#34;Tenancy: Mi Nombre del Tenant\u0026#34;, que en su caso será el nombre que hayan asignado al tenant: Y luego podrás observar: Lo copias y tendrás el Service Point para la configuración de Veeam Backup \u0026amp; Replication, que quedaría de la siguiente forma (en mi caso la región que use fue us-ashburn-1): ```text asdasdW$AWAXasda.compat.objectstorage.us-ashburn-1.oraclecloud.com Ahora que tenemos el Service Point, lo ingresamos en la configuración de Veeam, la Región y las Credenciales que generamos antes para poder acceder al servicio, si quieres puedes usar un Gateway Server definido en Veeam Backup \u0026amp; Replication para que haga la conexión vía Internet con el servicio y luego clic en siguiente, donde podremos ver el Bucket:\nLuego, generamos una carpeta dentro del Bucket, haciendo clic en \u0026ldquo;Browse\u0026rdquo; (En mi caso lo llame Respaldo, que original :) ):\nY solo si lo necesitas, puedes configurar el limite de uso del Bucket en relación a la cantidad de TB, de lo contrario, lo dejas sin configurar al igual que la inmutabilidad (recuerda que la que es solo compatible como Object Storage sin inmutabilidad), haces clic en \u0026ldquo;Next\u0026rdquo; y verás el resumen de la configuración:\nLuego editamos nuestro hermoso Scale-Out Backup Repository o SOBR de Veeam Backup \u0026amp; Replication para habilitar la función de Capacity Tier y seleccionar la forma de subir los respaldos:\nRecuerda que la primera opción de \u0026ldquo;Copy\u0026rdquo;, realizará la copia de los respaldos realizados por Veeam Backup \u0026amp; Replication a penas ellos terminen el Job de Backup, así te aseguras de tener la copia de tus respaldos casi al mismo tiempo que los tienes on-premises. Y la segunda opción de \u0026ldquo;Move\u0026rdquo;, te permite mover todos tus respaldos después de una cantidad de días para liberar espacio en tu storage o servidor local, permitiendo realizar recuperaciones tanto granulares como de maquinas virtuales completas directamente desde Object Storage.\nAplican la configuración y ejecutan un respaldo de sus maquinas virtuales para que luego puedan ver el envío de los datos directamente en las estadísticas de Veeam Backup \u0026amp; Replication:\nY por ultimo podrás certificar que tus respaldo están siendo enviados al servicio de Object Storage en Oracle Cloud, al ingresar a la consola de Oracle Cloud y navegar dentro del Bucket:\nEn la imagen anterior, vemos las carpetas creadas por Veeam Backup \u0026amp; Replication como también el respaldo que enviamos para almacenarlo.\nResumiendo, como pudimos observar, si es posible utilizar el servicio de Object Storage de Oracle Cloud con Veeam Backup \u0026amp; Replication para las personas que están evaluando el servicio o ya son clientes de Oracle Cloud.\nEsto demuestra completamente sobre la movilidad multicloud que posee Veeam Backup \u0026amp; Replication, lo que nos permite mantener copias de nuestros respaldos en múltiples plataformas o servicios Cloud para poder recuperarse rápidamente en caso de un desastre o ataque de ransomware.\nSaludos!\nPosts relacionados # Veeam Oracle RMAN Plugin Veeam Oracle Weblogic Veeam Cloud Connect Performance Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam ","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/posts/veeam-capacity-tier-oracle-cloud-object-storage/","section":"Blog","summary":"Últimamente algunas personas me han preguntado si Veeam posee soporte o funciona con el servicio de Object Storage de Oracle Cloud, para configurarlo en Veeam Capacity Tier y ya que en el anterior post hablamos sobre Oracle, en este post veremos como integrar el servicio de Oracle Cloud Object Storage con un Veeam Scale-Out Backup Repository o SOBR y demostrar las ventajas de poseer una solución con movilidad multicloud.","title":"Veeam Capacity Tier           Oracle Cloud Object Storage","type":"posts"},{"content":"","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/veeam-backup-amp-replication/","section":"Etiquetas","summary":"","title":"Veeam-Backup-\u0026Amp;-Replication","type":"tags"},{"content":"","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/veeam-capacity-tier/","section":"Etiquetas","summary":"","title":"Veeam-Capacity-Tier","type":"tags"},{"content":"","date":"21 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/veeam-sobr/","section":"Etiquetas","summary":"","title":"Veeam-Sobr","type":"tags"},{"content":"","date":"14 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/backup-amp-replication/","section":"Etiquetas","summary":"","title":"Backup-\u0026Amp;-Replication","type":"tags"},{"content":"","date":"14 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/cluster/","section":"Etiquetas","summary":"","title":"Cluster","type":"tags"},{"content":"","date":"14 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/oracle-asm/","section":"Etiquetas","summary":"","title":"Oracle-Asm","type":"tags"},{"content":"","date":"14 septiembre 2020","externalUrl":null,"permalink":"/en/tags/oracle-backup-veeam/","section":"Tags","summary":"","title":"Oracle-Backup-Veeam","type":"tags"},{"content":"","date":"14 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/oracle-rac/","section":"Etiquetas","summary":"","title":"Oracle-Rac","type":"tags"},{"content":"","date":"14 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/respaldo-oracle/","section":"Etiquetas","summary":"","title":"Respaldo-Oracle","type":"tags"},{"content":"","date":"14 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/respaldo-oracle-veeam/","section":"Etiquetas","summary":"","title":"Respaldo-Oracle-Veeam","type":"tags"},{"content":"","date":"14 septiembre 2020","externalUrl":null,"permalink":"/en/tags/rman-oracle-script/","section":"Tags","summary":"","title":"Rman-Oracle-Script","type":"tags"},{"content":"","date":"14 de septiembre de 2020","externalUrl":null,"permalink":"/es/tags/script-rman-oracle/","section":"Etiquetas","summary":"","title":"Script-Rman-Oracle","type":"tags"},{"content":" Esta vez revisaremos la instalación, configuración y respaldo con scripts (y por supuesto consejos) para dejar completamente funcional Veeam Oracle RMAN Plugin ya que por lo general, siempre me preguntan sobre esta solución en distintos lugares, ya que es una solución simple, flexible y confiable para almacenar los respaldos de RMAN (Recovery Manager). Este post solo se enfoca en Oracle RAC en Linux con ASM y la recuperación de Bases de Datos con Veeam Explorer for Oracle. Este es un post 4 en 1, para que vayan pasando por paginas al final de cada post.\nIntroducción # Primero que todo debemos saber algo muy importante, Veeam Oracle RMAN Plugin es una herramienta que trabaja en conjunto con Recovery Manager (RMAN) que es la solución de respaldo nativa de Oracle y la cual permite realizar respaldos soportados por el fabricante.\nDicho lo anterior, vamos a explicar brevemente que es y que hace Veeam Oracle RMAN Plugin, ya que como sabemos, el respaldo lo hace RMAN trabajando en conjunto con el Plugin.\nPor supuesto existen otras formas de respaldo de Bases de Datos de Oracle con Veeam, como por ejemplo con Veeam Agent for Linux o la integración nativa para Oracle en ambientes virtualizados, estas formas las veremos en otros posts.\nQue es Veeam Oracle RMAN Plugin? # Este Plugin es una solución de Veeam Certificada por Oracle ( Link de la Certificación) para realizar respaldos con RMAN y guardarlos en el repositorio de Veeam Backup \u0026amp; Replication. Así podrás almacenar los respaldos de tus bases de datos Oracle que se encuentren en Cluster, Oracle RAC, o sin cluster, standalone usando ASM y por supuesto realizar la recuperación a través de Veeam Explorer for Oracle RMAN\nTécnicamente lo que realiza Veeam Oracle RMAN Plugin, es funcionar como una librería SBT para configurarse con RMAN y éste último utilice la librería para acceder a los repositorios de Veeam VBR y alojar los respaldos con la política de respaldo que se utilice con RMAN.\nInstalación # Primero que todo y antes de instalar, se debe cumplir con los requerimientos de sistema y versiones soportadas de Veeam Oracle RMAN Plugin, que los puedes encontrar en el siguiente enlace:\nhttps://helpcenter.veeam.com/docs/backup/plugins/system_requirements.html?ver=100\nEl Oracle RAC que tengo instalado en mi laboratorio consta de 2 nodos con los siguientes detalles:\nComponente Valor Sistema Operativo Oracle Linux 7.8 CPU 8 vCPU RAM 16 GB Disco S.O 50 GB Disco Oracle iSCSI 8 x 20 GB (Compartido) Versión Oracle 19.3.0.0.0 Versión Oracle Grid 19.0.0.0.0 ASM Sí Bases de Datos BRAZIL, CHILE, RAC19C Tabla: Detalles del Oracle RAC Lab 24xSiempre\nVista de la configuración del RAC con el comando:\nLuego de estar completamente seguros que tenemos las versiones soportadas, necesitamos descargar o montar la ISO de Veeam Backup \u0026amp; Replication para copiar el paquete de instalación de Veeam Oracle RMAN Plugin:\nEn mi caso y a la fecha de este post, la última versión de Veeam Oracle RMAN Plugin es:\nVeeamPluginforOracleRMAN-10.0.1.4854-1.x86_64.rpm ```bash Donde utilizaremos la versión de 64bits y el paquete RPM para instalarlo en todos los nodos de Oracle RAC, **que es la forma recomendada**, ya que RMAN puede decidir por que nodo realizar el respaldo a través de una característica llamada RMAN Node Affinity Awareness. Copiamos el archivo a los nodos, o como tu quieras, en mi caso lo haré con WinSCP: Como se ve en la imagen anterior, he copiado **con el usuario root** el rpm a ambos nodos del RAC (20.20.20.91 y 20.20.20.92). **_Algo muy importante y clave para la instalación de Veeam Oracle RMAN Plugin es que se debe instalar con el usuario \u0026#34;root\u0026#34; y luego configurar con el usuario de Oracle que generalmente es \u0026#34;oracle\u0026#34;. Esto utilízalo como regla general, ya que si configuras con \u0026#34;root\u0026#34; no tendrás acceso a las variables de entorno de Oracle y por tanto tendrás errores._** Ahora instalaremos el plugin en ambos nodos con el siguiente comando: ```bash Linux rpm -ivh VeeamPluginforOracleRMAN-10.0.1.4854-1.x86_64.rpm Solaris SPARC pkgadd -d /VeeamPluginforOracleRMAN-10.0.1.4854-1.SPARC.pkg ```bash Ya que mi Oracle RAC esta en Oracle Linux utilizare el comando para Linux, en caso de que tengas un Oracle RAC sobre SPARC, debes usar el comando para ese sistema operativo. Al ejecutar en cada nodo, obtendrás como resultado: ```bash Nodo 1: [root@rac19cn1 ~]# rpm -ivh VeeamPluginforOracleRMAN-10.0.1.4854-1.x86_64.rpm Preparing... ################################# [100%] Updating / installing... 1:VeeamPluginforOracleRMAN-10.0.1.4################################# [100%] Run \u0026#34;OracleRMANConfigTool --wizard\u0026#34; to configure the Veeam Plug-in for Oracle RMAN [root@rac19cn1 ~]# Nodo 2: [root@rac19cn2 ~]# rpm -ivh VeeamPluginforOracleRMAN-10.0.1.4854-1.x86_64.rpm Preparing... ################################# [100%] Updating / installing... 1:VeeamPluginforOracleRMAN-10.0.1.4################################# [100%] Run \u0026#34;OracleRMANConfigTool --wizard\u0026#34; to configure the Veeam Plug-in for Oracle RMAN [root@rac19cn2 ~]# ```bash Y como explique anteriormente, para la configuración, utilizaremos el usuario de Oracle que en este caso es \u0026#34;oracle\u0026#34;. ## Configuración Ahora debemos conectarnos vía SSH con el usuario \u0026#34;oracle\u0026#34; o el que pertenezca a la instalación de Oracle para ejecutar la configuración del Plugin para Oracle RMAN de Veeam. Algo muy importante es que el usuario se encuentre cargando las variables de entorno de oracle, si no, cargar el perfil. Muchas veces distintos administradores de bases de datos o DBA\u0026#39;s prefieren mantener archivos de perfiles por cada instancia de Oracle u otros configuran directamente las variables en el perfil del usuario por defecto. Cuando realicen la configuración, primero validen como se carga el perfil y sus respectiva configuraciones. Como nos indico el mensaje cuando instalamos el plugin,debemos ejecutar el comando \u0026#34;OracleRMANConfigTool --wizard\u0026#34; con el usuario oracle y nos arrojará lo siguiente: ```python [oracle@rac19cn2 ~]$ OracleRMANConfigTool --wizard Enter backup server name or IP address: veeam24xs.24xsiempre.cl Enter backup server port [10006]: Enter username: 24xsiempre\\veeam Enter password for 24xsiempre\\veeam: Veeam repositories: 1. Default Backup Repository Specify up to 4 Veeam repositories to use as target using whitespace as a separator: 1 Enter the number of data streams (From 1 to 254) to send to each repository concurrently(RMAN DEVICE PARALLELISM value). Channel count per device [1]: 4 Enable Veeam compression? (Y/n): n Cannot find any Oracle instances. Please apply the following RMAN settings manually: CONFIGURE DEFAULT DEVICE TYPE TO SBT_TAPE; CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE PARMS \u0026#39;SBT_LIBRARY=/opt/veeam/VeeamPluginforOracleRMAN/libOracleRMANPlugin.so\u0026#39; FORMAT \u0026#39;88788f9e-d8f5-4eb4-bc4f-9b3f5403bcec/RMAN_%I_%d_%T_%U.vab\u0026#39;; CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 4; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO \u0026#39;%F_RMAN_AUTOBACKUP.vab\u0026#39;; Channel definition for RMAN scripts: ALLOCATE CHANNEL VeeamAgentChannel1 DEVICE TYPE SBT_TAPE PARMS \u0026#39;SBT_LIBRARY=/opt/veeam/VeeamPluginforOracleRMAN/libOracleRMANPlugin.so\u0026#39; FORMAT \u0026#39;88788f9e-d8f5-4eb4-bc4f-9b3f5403bcec/RMAN_%I_%d_%T_%U.vab\u0026#39;; Save configuration? 1. Apply configuration to the Oracle environment 1. Export configuration into a file for manual setup 1. Cancel without saving Enter:3 *** No Oracle database instances were configured *** ```bash Como se puede observar en el log anterior, existen dos lineas marcadas la 7 y la 12, como también, que no se pudo configurar el Plugin. En relación a la linea 7, esto solo muestra los repositorio donde el usuario haya permitido acceso, es decir, en la configuración de Repositorios de Veeam Backup \u0026amp; Replication, en la parte de \u0026#34;Access Permissions\u0026#34; por defecto, siempre esta permitido el acceso al Default Backup Repository y cuando configuramos por primera vez el Plugin, siempre veremos este repositorio, por ejemplo: Para dar acceso a otros Repositorios, recomiendo dejar \u0026#34;Deny to Everyone\u0026#34; el \u0026#34;Default Backup Repository\u0026#34; o solo permitir a los usuarios que accederán vía Veeam Oracle RMAN Plugin, en mi caso, bloquearé el acceso al Default Repository y permitiré el Acceso a un Scale-Out Backup Repository (SOBR) para guardar los respaldos: De acuerdo al punto 12, éste, tiene directa relación a la versión de Oracle que se este ejecutando en un RAC ya que a partir de la versión 12.2.0.1.171017 GI RU/PSU (patch 26737266) y 12.2.0.1.171017 OCW RU/PSU (patch 26729536). MOS Note Doc ID 2329359.1, ha cambiado la forma de actualizar las instancias en el archivo /etc/oratab, es decir, el archivo mencionado ya no se actualiza con los nombres de instancias ejecutándose en el Oracle RAC. Cuando se configura Veeam Oracle RMAN Plugin, lee el archivo /etc/oratab para detectar los nombres de instancias, pero si en este archivo no se encuentran las instancias, lamentablemente no será posible configurar el plugin. Existen dos soluciones, la primera es que se agregue manualmente el nombre de cada instancia que se ejecuta en Oracle RAC (la cual no me gusta) y la segunda opción es ejecutar un script para que lea las instacias del RAC y actualice el archivo /etc/oratab, para ello, aquí realizaremos la implementación del script para automatizar la actualización de ese archivo. \\\\*\\\\* En la versión 11 de Veeam Backup \u0026amp; Replication Ya no sera necesario utilizar este workaround\\*\\* Como recomendación, se debe ejecutar en todos los nodos del Oracle RAC (RMAN Node Affinity Awareness): ```bash original=\u0026#34;#\\n\\n\\n\\n# This file is used by ORACLE utilities. It is created by root.sh\\n# and updated by either Database Configuration Assistant while creating\\n# a database or ASM Configuration Assistant while creating ASM instance.\\n\\n# A colon, \u0026#39;:\u0026#39;, is used as the field terminator. A new line terminates\\n# the entry. Lines beginning with a pound sign, \u0026#39;#\u0026#39;, are comments.\\n#\\n# Entries are of the form:\\n# $ORACLE_SID:$ORACLE_HOME:\u0026lt;N|Y\u0026gt;:\\n#\\n# The first and second fields are the system identifier and home\\n# directory of the database respectively. The third field indicates\\n# to the dbstart utility that the database should , \u0026#34;Y\u0026#34;, or should not,\\n# \u0026#34;N\u0026#34;, be brought up at system boot time.\\n#\\n# Multiple entries with the same $ORACLE_SID are not allowed.\\n# \\n# \\n\u0026#34; path=\u0026#34;/oracle/grid/19.3.0/grid_home/bin/crsctl\u0026#34; cat /dev/null \u0026gt; /etc/oratab printf \u0026#34;$original\u0026#34; \u0026gt;\u0026gt; /etc/oratab for resource in $($path status resource -w \u0026#34;((TYPE = ora.database.type) AND (LAST_SERVER = $(hostname -s)))\u0026#34; | grep ^NAME | sed \u0026#39;s/.*=//\u0026#39;); do full_resource=$($path status resource -w \u0026#34;((NAME = $resource) AND (LAST_SERVER = $(hostname -s)))\u0026#34; -f) db_name=$(echo \u0026#34;$full_resource\u0026#34; | grep ^DB_UNIQUE_NAME | awk -F= \u0026#39;{ print $2 }\u0026#39;) ora_home=$(echo \u0026#34;$full_resource\u0026#34; | grep ^ORACLE_HOME= | awk -F= \u0026#39;{ print $2 }\u0026#39;) instance=\u0026#34;1\u0026#34; #Cambiar numero de acuerdo al numero de nodo e instancia oracle=\u0026#34;$db_name$instance:$ora_home:N \\n\u0026#34; printf \u0026#34;$oracle\u0026#34; \u0026amp;\u0026gt;\u0026gt; /etc/oratab done #Reconfiguro Oracle Plugin echo=\u0026#34;\u0026#34; no=\u0026#34;n\u0026#34; #cambiar por \u0026#34;y\u0026#34; si necesitas habilitar compresion de Veeam uno=\u0026#34;1\u0026#34; #aplica cambios exec \u0026gt;\u0026gt; /home/oracle/veeam.log 2\u0026gt;\u0026amp;1 #log en ruta OracleRMANConfigTool --wizard \u0026lt;\u0026lt;EOF $echo $echo $echo $echo $echo $echo $no $uno EOF ```bash Copiar el archivo a los nodos, con el nombre addoratab.sh y asignarle permisos de ejecución con chmod +x addoratab.sh. **Algo clave como se ve en la linea 10, el numero se debe cambiar de acuerdo al nodo de RAC ya que por ejemplo en el nodo 1 el nombre de la instancia seria \u0026#34;CHILE1\u0026#34; y en el nodo 2 seria \u0026#34;CHILE2\u0026#34;**. Y por supuesto ejecutar el script con sh addoratad.sh o ./addoratab.sh con el usuario \u0026#34;oracle\u0026#34;. Y podrás observar el archivo actualizado con el comando cat /etc/oratab. Luego de la configuración de permisos del repositorio de Veeam Backup \u0026amp; Replication, la actualización del archivo /etc/oratab a través del script, volvemos a ejecutar el wizard del plugin, lo que nos mostrará lo siguiente: ```python [oracle@rac19cn1 ~]$ OracleRMANConfigTool --wizard Enter backup server name or IP address: veeam24xs.24xsiempre.cl Enter backup server port [10006]: Enter username: 24xsiempre\\veeam Enter password for 24xsiempre\\veeam: Veeam repositories: 1. SOBR Specify up to 4 Veeam repositories to use as target using whitespace as a separator: 1 Enter the number of data streams (From 1 to 254) to send to each repository concurrently(RMAN DEVICE PARALLELISM value). Channel count per device [1]: 4 Enable Veeam compression? (Y/n): n RMAN settings will be applied automatically to the following databases: ORACLE_SID=BRAZIL1 ORACLE_HOME=/oracle/db/19.3.0/db_home ORACLE_SID=CHILE1 ORACLE_HOME=/oracle/db/19.3.0/db_home ORACLE_SID=RAC19C1 ORACLE_HOME=/oracle/db/19.3.0/db_home RMAN settings: CONFIGURE DEFAULT DEVICE TYPE TO SBT_TAPE; CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE PARMS \u0026#39;SBT_LIBRARY=/opt/veeam/VeeamPluginforOracleRMAN/libOracleRMANPlugin.so\u0026#39; FORMAT \u0026#39;60fc82ee-cedc-458f-beda-346323f93c1e/RMAN_%I_%d_%T_%U.vab\u0026#39;; CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 4; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO \u0026#39;%F_RMAN_AUTOBACKUP.vab\u0026#39;; Channel definition for RMAN scripts: ALLOCATE CHANNEL VeeamAgentChannel1 DEVICE TYPE SBT_TAPE PARMS \u0026#39;SBT_LIBRARY=/opt/veeam/VeeamPluginforOracleRMAN/libOracleRMANPlugin.so\u0026#39; FORMAT \u0026#39;60fc82ee-cedc-458f-beda-346323f93c1e/RMAN_%I_%d_%T_%U.vab\u0026#39;; Save configuration? 1. Apply configuration to the Oracle environment 1. Export configuration into a file for manual setup 1. Cancel without saving Enter: 1 *** Database instance BRAZIL1 is configured *** *** Database instance CHILE1 is configured *** *** Database instance RAC19C1 is configured *** [oracle@rac19cn1 ~]$ ```text Como vemos, en la linea 7 ya solo muestra el SOBR que se asigno para los respaldo de Oracle con Veeam Oracle RMAN Plugin y en las lineas 13,14,15, se observa que reconoce las instancias de RAC para que RMAN quede configurado para proceder al respaldo. Algo muy importante, **¿que pasa si después agrego otra instancia al Oracle RAC?**. Simple, si no agregas nuevamente la instancia al archivo /etc/oratab, Veeam Oracle RMAN Plugin no lo procesará, es por ello, que aqui viene una solución o un consejo muy bueno. El script addoratab.sh ya esta preconfigurado para que cuando se agende la ejecucion diaria del script addoratab.sh, éste automaticamente agregue la nueva instancia y reconfigure el Veeam Oracle RMAN Plugin, sin la necesidad de intervencion manual. Solo debes agendarlos en crontab con el usuario \u0026#34;oracle\u0026#34;, como por ejemplo: ```text [oracle@rac19cn1 ~]$ crontab -e y luego agregar: 0 0 1 ? * * * /home/oracle/addoratab.sh Cerrar con esc:wq Se ejecuta todos los dias a las 1 AM ```powershell ## Respaldo Para respaldar las bases de datos del RAC, literalmente es a gusto del consumidor o en este caso, de los DBA\u0026#39;s ya que generalmente los DBA\u0026#39;s mantienen sus hermosos scripts para respaldar las bases de datos. Que pasa si no tengo Script y necesito respaldar mi Oracle RAC? aquí dejaré un script para hacer respaldo de todas las instancias que se encuentren en el Oracle RAC, utilizando el usuario \u0026#34;oracle\u0026#34;, logueando todos los comandos, buscando errores en caso de existir alguno y por supuesto enviar alertas por correo. (Debes configurar mailx) ```bash #!/bin/bash . /home/oracle/.bash_profile #Carga variables de Entorno del Perfil y usuario Oracle MAQUINA=`hostname` #Seteo Variable Nombre de Maquina LOG=/home/oracle/ #Carpeta donde alojar logs HORA=`date +%H%M_%d%m%Y` #Sintaxys Hora FECHA=`date +%d%m%Y` #Sintaxys Fecha CORREO=tu-correo@ejemplo.com Append=1 #numero de nodo donde se ejecuta #Comienzo Script for ORACLE_SID in $($ORACLE_HOME/bin/srvctl config database) #Loop para extraer nombre de SID en archivo do export ORACLE_SID=$ORACLE_SID$Append LOGFILE=${LOG}/${ORACLE_SID}_${FECHA}_${HORA}.log #Construye Nombre de Arhivo Log exec \u0026gt;\u0026gt; ${LOGFILE} 2\u0026gt;\u0026amp;1 #Escribe Log #Ejecucion RMAN, aqui puede ir el script de RMAN del Cliente ${ORACLE_HOME}/bin/rman \u0026lt;\u0026lt;EOF connect target / run { backup database plus archivelog; } LIST BACKUP SUMMARY; EOF echo Base de Datos: \u0026#34;${ORACLE_SID}\u0026#34; \u0026gt;\u0026gt; ${LOG}/mail #Escribe el SID en log mail para envia el nombre cat ${LOGFILE} \u0026gt;\u0026gt; ${LOG}/mail #Lee el Archivo log y lo inserta al mail done # Fin del Loop grep RMAN-06273 ${LOG}/mail \u0026gt;\u0026gt;/dev/null #Busca error RMAN en caso de falla. if [ $? -eq 0 ] # Si es distinto a 0 pasa a la sigueinte instruccion si es igual a 0 envia correo con alerta then ASUNTO=\u0026#39;ALERTA!: Respaldo de \u0026#39;${MAQUINA}\u0026#39; ha fallado\u0026#39; #Configuracion Asunto Alerta 1 else grep -i error ${LOGFILE} \u0026gt;\u0026gt;/dev/null #Busca la palabra error if [ $? -eq 0 ] #Si es distinto a 0 pasa a la sigueinte instruccion si es igual a 0 envia correo con alerta then ASUNTO=\u0026#39;ALERTA!: Respaldo de \u0026#39;${MAQUINA}\u0026#39; ha fallado\u0026#39; #Configuracion Asunto Alerta 2 else ASUNTO=\u0026#39;Respaldo \u0026#39;${MAQUINA}\u0026#39; Correcto\u0026#39; #Sitodo esta OK, enviara correo con Asunto correcto. fi fi ## Mail ## cat ${LOG}/mail | /usr/bin/mailx -s \u0026#34;${ASUNTO}\u0026#34; \u0026#34;${CORREO}\u0026#34; #Lee el archivo Mail para enviarlo como cuerpo del correo. rm -rf ${LOG}/mail #elimino log utilizado echo $exit 0 En las lineas 17 a la 21, en donde van las instrucciones de RMAN para realizar el respaldo, puedes editar el script como quieras, solo no olvides cambiar el correo y algunos parámetros que se observan, como el numero de nodo donde se ejecuta por ejemplo. Este script hace un respaldo full de las bases de datos incluyendo los ArchiveLogs.\nPara los mas ñoños, el script recorre las instancias a través de un \u0026ldquo;for\u0026rdquo; utilizando el comando srvctl config database y le agrega el numero de nodo a la instancia para ingresar a RMAN y ejecutar el respaldo, cuando termina con una instancia, seguirá respaldando la siguiente hasta terminar todas las instancias.\nAl ejecutar el script de respaldo, se obtendrá lo siguiente:\nPodrán ver los logs de ejecución de RMAN de cada una de las instancias y si tienen configurado el mailx les llegara la notificación de respaldo exitoso. Ademas, podrán ver el respaldo exitoso en Veeam Backup \u0026amp; Replication:\nCon esto ya tenemos nuestros respaldos de las instancias de Oracle RAC funcionando fácilmente, por ejemplo, si deseas agendar el respaldo solo debes agregar el script backup.sh a crontab en los días que estimes convenientes y editar la parte de RMAN para hacer el respaldo como estimes necesario, o ejecutarlo con tu gestor preferente o con Veeam Agent for Linux si lo tienes instalado y haces respaldo de algunos archivos.\nRecuperación # Ya que tenemos respaldos, nos aparecerán en el menú de la consola de Veeam Backup \u0026amp; Replication, después de Backup en Disks:\nY podremos seleccionar el respaldo para restaurarlo en caso de algún problema:\nY podremos ver Veeam Explorer para Oracle RMAN:\nSeleccionar la base de datos a recuperar y configurar los requerimientos:\nComo siempre importante leer informacion especifica del manual de Veeam:\nhttps:// helpcenter.veeam.com /docs/ backup /explorers/veor_considerations.html?ver=100\nO también lo puedes recuperar directamente desde RMAN con sus respectivos comandos.\nLogs # Los archivos de logs, en caso de problemas tanto de instalación o de configuración se encuentran en la ruta: /tmp/veeam_plugin_logs donde podrás buscar los errores o enviarlos a soporte de Veeam en caso de algún problema, como también los logs que generan los scripts addoratab.sh y backup.sh que los guarda en /home/oracle/.\nCon lo ultimo finalizamos este primer post del blog :) Que te parece para ser el primero? Deja tus comentarios o valoralo.\nPosts relacionados # Buenas Prácticas Veeam Plugin Oracle RMAN Veeam Explorer Oracle RMAN Solución Veeam Oracle Permission Denied Veeam Agent Linux - Oracle Linux / Exadata Protegiendo Oracle KVM con Veeam Veeam Capacity Tier Oracle Cloud Object Storage ","date":"14 de septiembre de 2020","externalUrl":null,"permalink":"/es/posts/veeam-oracle-rman-plugin/","section":"Blog","summary":"Esta vez revisaremos la instalación, configuración y respaldo con scripts (y por supuesto consejos) para dejar completamente funcional Veeam Oracle RMAN Plugin ya que por lo general, siempre me preguntan sobre esta solución en distintos lugares, ya que es una solución simple, flexible y confiable para almacenar los respaldos de RMAN (Recovery Manager). Este post solo se enfoca en Oracle RAC en Linux con ASM y la recuperación de Bases de Datos con Veeam Explorer for Oracle. Este es un post 4 en 1, para que vayan pasando por paginas al final de cada post.","title":"Veeam Oracle RMAN Plugin","type":"posts"},{"content":" Marco Escobar # Lead Solutions Architect @ Veeam · LATAM\nMás de 11 años en Veeam cubriendo clientes enterprise en LATAM y USA. Escalamiento técnico de deals complejos y referente técnico regional para ventas, partners y clientes en Chile, Brasil, México, Argentina, Colombia y otros mercados de la región.\nMi día a día combina arquitectura de data protection, discovery sessions con clientes, POCs y bajar soluciones a tierra en ambientes que van desde bancos y mineras hasta proveedores cloud.\nFuera del rol formal me gusta construir: herramientas de seguridad, frameworks de governance para IA, integraciones, automatización. Casi siempre resolviendo primero un problema propio antes de evaluar si tiene sentido convertirlo en producto. Últimamente enfocado en la intersección entre ciberseguridad, IA y data protection, donde creo que está la estrategia de los próximos años.\n24xsiempre.com es donde comparto lo que aprendo con la comunidad de Solution Architects y sysadmins de la región: deep-dives técnicos, configuraciones reales y experimentos del laboratorio.\nExperiencia técnica # Data Protection # Veeam Data Platform: VBR, Veeam ONE, Veeam Recovery Orchestrator, Veeam Data Cloud Veeam Backup para Microsoft 365, Salesforce, AWS, Azure, GCP, Nutanix AHV, Red Hat Kasten K10: Protección y DR nativo de Kubernetes Oracle: RMAN, RAC, ASM, Data Guard (on-premise y Exadata Cloud@Customer) Plataformas y Cloud # Kubernetes: OpenShift, EKS, AKS, GKE, Tanzu, Rancher Virtualización: VMware vSphere, Hyper-V, Proxmox, HPE VM Essentials, KVM, oVirt, OpenShift Virtualization, Rancher Harvester, KubeVirt Cloud pública e híbrida: AWS, Azure, GCP, OCI Sistemas: Linux a nivel kernel, Windows Server, PowerShell, Bash, Rust Ciberseguridad # Ransomware protection y arquitecturas de backup inmutable Hardening (STIG, CIS), PAM, security validation de appliances Pentest y análisis de vulnerabilidades Frameworks de seguridad y estándares Incident response alineado con NIST SP 800-61r3 Threat intel, eBPF, detección y honeypots IA y Automatización # Diseño de agentes autónomos para workflows técnicos y de presales Governance de IA en entornos enterprise Integraciones con Copilot Studio, Salesforce y orquestación multi-agente MCP (Model Context Protocol) para conectar LLMs con herramientas internas Presales y Consulting # Diseño de arquitectura y technical validation para deals enterprise POCs, respuesta a RFP/RFI, competitive positioning Technical enablement de partners y equipos regionales Leadership y comunidad # Más allá del rol individual, buena parte de lo que hago es multiplicar capacidad técnica en el equipo y la región.\nTrusted Advisor para clientes enterprise estratégicos y los equipos de ventas que los cubren, desde la arquitectura inicial hasta el cierre del deal. Mentoring y enablement de SAs junior y partners en LATAM: sesiones técnicas, shadowing en deals complejos y frameworks internos que bajan la curva de aprendizaje. Evangelización técnica en eventos, webinars y contenido público. Represento a Veeam frente a la comunidad técnica de la región. Escalamiento cross-funcional con product management y engineering: llevo feedback real de nuestros clientes en LATAM a las decisiones de producto, como también propuesta de nuevas características para todos los productos. Herramientas internas que usan otros equipos: frameworks de governance, generadores de documentación y automatización de tareas repetitivas de presales. Contacto # LinkedIn: linkedin.com/in/24xsiempre GitHub: github.com/mescobarcl Email: marco [arroba] 24xsiempre.com ","externalUrl":null,"permalink":"/es/about/","section":"Inicio","summary":"","title":"Acerca de","type":"page"},{"content":"","externalUrl":null,"permalink":"/es/posts/","section":"Blog","summary":"","title":"Blog","type":"posts"},{"content":"","externalUrl":null,"permalink":"/es/categories/","section":"Categorías","summary":"","title":"Categorías","type":"categories"},{"content":"","externalUrl":null,"permalink":"/es/tags/","section":"Etiquetas","summary":"","title":"Etiquetas","type":"tags"},{"content":"","externalUrl":null,"permalink":"/es/","section":"Inicio","summary":"","title":"Inicio","type":"page"}]