{"id":84809,"date":"2020-06-11T01:42:41","date_gmt":"2020-06-10T23:42:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10"},"modified":"2020-06-11T01:42:41","modified_gmt":"2020-06-10T23:42:41","slug":"chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>El Capacity Tier (o como lo llamamos internamente en Vima \u2014 captir) apareci\u00f3 en la \u00e9poca de Veeam Backup and Replication 9.5 Update 4 con el nombre de Archive Tier. La idea subyacente es permitir mover copias de seguridad que han ca\u00eddo fuera de la llamada ventana de restauraci\u00f3n operativa a almacenes de objetos. Esto ayudaba a liberar espacio en disco para aquellos usuarios que ten\u00edan poco. Esta opci\u00f3n se llamaba Move Mode.<\/p>\n<p>Para realizar esta acci\u00f3n sencilla (como parece) solo era necesario cumplir con dos condiciones: todos los puntos de la copia de seguridad que se va a mover deben estar fuera de la mencionada ventana de restauraci\u00f3n operativa, que se establece expl\u00edcitamente en la interfaz. Y la segunda: la cadena debe estar en lo que se llama \u00abestado sellado\u00bb (sealed backup chain o Inactive Backup Chain). Esto significa que con el tiempo no se producen cambios en esta cadena.<\/p>\n<p>Pero en VBR v10, la concepci\u00f3n se complement\u00f3 con nuevas funciones: apareci\u00f3 el Copy Mode, Sealed Mode y una cosa con un nombre dif\u00edcil de pronunciar: Immutability.<\/p>\n<p>Hoy vamos a hablar de estas emocionantes cosas. Primero, c\u00f3mo funcionaba en VBR9.5u4, y luego los cambios en la d\u00e9cima versi\u00f3n.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nY que me perdonen los defensores del lenguaje puro, pero no es posible traducir demasiados t\u00e9rminos.<br \/>\nAs\u00ed que aqu\u00ed habr\u00e1 un mont\u00f3n de anglicismos.<br \/>\nY muchas gifs. <br \/>\nY im\u00e1genes.<\/p>\n<ul>\n<li>Sin el m\u00e1s m\u00ednimo arrepentimiento. Autor del art\u00edculo.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Como fue<\/h1>\n<p>\nBueno, empecemos con el an\u00e1lisis de la ventana de restauraci\u00f3n operativa y la copia de seguridad sellada (o como se llama en la documentaci\u00f3n, Inactive Backup Chain). Sin su comprensi\u00f3n, no se podr\u00e1 explicar nada m\u00e1s.<\/p>\n<p>Como podemos ver en la imagen, tenemos una cadena de copia de seguridad con bloques de datos, que est\u00e1 situada en el performance tier del repositorio SOBR, al cual est\u00e1 conectado el Capacity Tier. Nuestra ventana de copia de seguridad operativa es de tres d\u00edas.<\/p>\n<p>Por lo tanto, la copia .vbk creada el lunes sella la cadena anterior, cuya ventana est\u00e1 establecida en tres d\u00edas. Y, por lo tanto, se puede comenzar a llevar al capacity tier todo lo que tenga m\u00e1s de esos tres d\u00edas.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPero, \u00bfqu\u00e9 se entend\u00eda exactamente por una cadena sellada y qu\u00e9 pod\u00eda enviarse al capacity tier en la actualizaci\u00f3n 4?<\/p>\n<p>Para Forward Incremental, el signo de un sellado de la cadena es la creaci\u00f3n de una nueva copia de seguridad completa. Y no importa c\u00f3mo se obtenga esa copia completa: se consideran tanto las copias completas sint\u00e9ticas como las copias completas activas.<\/p>\n<p>En el caso de Reverse, son todos los archivos que no caen dentro de la ventana operativa. <\/p>\n<p>En el caso de Forward increment con rollbacks, todos los rollbacks y .vbk, si hay otro .vbk en el performance extent.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAhora consideremos una opci\u00f3n de trabajo con cadenas de Backup Copy. Aqu\u00ed solo se inclu\u00eda lo que estaba bajo la retenci\u00f3n de GFS. Porque todo lo que se almacene en cadenas de backup copy m\u00e1s recientes puede ser de alguna manera modificado.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAhora echemos un vistazo bajo el cap\u00f3. All\u00ed ocurre un proceso llamado deshidrataci\u00f3n, que consiste en dejar residuos de archivos de backup en el extent y trasladar bloques de estos archivos al capacity tier. Para optimizar este proceso se utiliza lo que se llama un \u00edndice de deshidrataci\u00f3n, que permite no copiar bloques que ya han sido transferidos al capacity tier. <\/p>\n<p>Veamos c\u00f3mo se ve esto con un ejemplo: supongamos que tenemos un .vbk que ha salido de la ventana operativa y pertenece a una cadena sellada. Esto significa que tenemos todo el derecho de transferirlo al capacity tier. En el momento de la transferencia, se crea un archivo de metadatos en el capacity tier y se trasladan los bloques del archivo transferido. En el archivo de metadatos a nivel de referencias se describe de qu\u00e9 bloques consta nuestro archivo. En el caso de la imagen, nuestro primer archivo consta de bloques a, b, c y en los metadatos se colocan referencias a estos bloques. Cuando tenemos un segundo archivo .vbk listo para trasladarse y compuesto por bloques a, b y d, al analizar el \u00edndice de deshidrataci\u00f3n entendemos que solo es necesario trasladar el bloque d. Su archivo de metadatos contendr\u00e1 referencias a los dos bloques anteriores y uno nuevo.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor lo tanto, el proceso de volver a llenar estos residuos con datos se llama rehidrataci\u00f3n. Aqu\u00ed se utiliza su propio \u00edndice de rehidrataci\u00f3n, que se basa en el archivo .vbk m\u00e1s antiguo en el performance extent local. Es decir, si el usuario desea recuperar un archivo del capacity tier, primero creamos un \u00edndice de bloques de la copia de seguridad completa m\u00e1s antigua y solo trasladamos los bloques faltantes desde el capacity tier. En el caso presentado en la imagen, para rehidratar FullBackup1.vbk de acuerdo con el \u00edndice de rehidrataci\u00f3n solo nos falta el bloque C, que retiramos del capacity tier. Si el capacity tier es un almacenamiento de objetos en la nube, esto permite ahorrar enormes sumas de dinero.<\/p>\n<p>Aqu\u00ed puede parecer que esta tecnolog\u00eda es id\u00e9ntica a la utilizada en los aceleradores WAN, pero solo lo parece. En los aceleradores, la deduplicaci\u00f3n es global; aqu\u00ed se utiliza de manera local dentro de cada archivo a un determinado offset. Esto se debe a la diferencia en los problemas que se resuelven: aqu\u00ed necesitamos copiar grandes archivos de respaldos completos, y seg\u00fan nuestras investigaciones, incluso si entre ellos transcurre un largo per\u00edodo de tiempo, dicho algoritmo de deduplicaci\u00f3n da el mejor resultado.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00a1Pero m\u00e1s \u00edndices al dios de los \u00edndices! \u00a1Tambi\u00e9n hay un \u00edndice para la recuperaci\u00f3n de datos! Cuando iniciamos la recuperaci\u00f3n de una m\u00e1quina ubicada en un \u00e1rea de capacidad, solo leeremos bloques de datos \u00fanicos que no est\u00e1n en el \u00e1rea de rendimiento.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Como se ha dicho<\/h1>\n<p>\nCon esto hemos terminado la parte introductoria. Es bastante detallada, pero, como se mencion\u00f3 anteriormente, sin estos detalles no se puede explicar c\u00f3mo funcionan las nuevas funciones. Por lo tanto, sin m\u00e1s pre\u00e1mbulos, pasemos al primero.<\/p>\n<h3>Modo de copia<\/h3>\n<p>\nSe basa en gran medida en tecnolog\u00edas existentes, pero lleva consigo una l\u00f3gica de uso completamente diferente.\u00a0<\/p>\n<p>El objetivo de este modo es garantizar que todos los datos ubicados en el extent local tengan una copia en el \u00e1rea de capacidad.<\/p>\n<p>Si comparamos directamente los modos Move y Copy, quedar\u00eda as\u00ed:<\/p>\n<ul>\n<li>Solo se puede mover una cadena sellada. En el caso del modo de copia, se transporta absolutamente todo, independientemente de lo que ocurra en el trabajo de respaldo.<\/li>\n<li>El movimiento se activa cuando los archivos est\u00e1n fuera de las ventanas de operaci\u00f3n del respaldo, mientras que la copia se activa tan pronto como aparece un archivo de respaldo.<\/li>\n<li>El seguimiento de nuevos datos para copiar ocurre de manera constante, mientras que para el movimiento se activa cada 4 horas.<\/li>\n<\/ul>\n<p>\nAl considerar el nuevo modo, propongo avanzar de ejemplos simples a complejos.<\/p>\n<p>En el caso m\u00e1s simple, simplemente nos aparecen nuevos archivos con incrementos, y simplemente los copiamos en el \u00e1rea de capacidad. Sin importar qu\u00e9 modo se use en el trabajo de respaldo, sin importar si pertenece a la parte sellada de la cadena o no, sin importar si ha expirado nuestra ventana operativa. Simplemente tomamos y copiamos.<\/p>\n<p>El proceso detr\u00e1s de esto sigue siendo la deshidrataci\u00f3n tal como se describi\u00f3 anteriormente. En modo de copia, tambi\u00e9n se asegura de que no copiemos bloques que ya est\u00e1n en nuestro almacenamiento. La \u00fanica diferencia es que, en modo de movimiento, reemplaz\u00e1bamos los archivos reales con archivos vac\u00edos, mientras que aqu\u00ed no los tocamos y los dejamos tal como est\u00e1n. En el resto, es exactamente el mismo \u00edndice de deshidrataci\u00f3n, que se esfuerza por ahorrar su dinero y tiempo.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSurge la pregunta: si miramos en la interfaz de usuario, hay una opci\u00f3n para seleccionar ambas opciones al mismo tiempo. \u00bfC\u00f3mo funcionar\u00e1 este modo combinado?<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVamos a analizarlo.<\/p>\n<p>El inicio es est\u00e1ndar: se crea un archivo de respaldo y se copia de inmediato. Se crea un incremento y tambi\u00e9n se copia. Esto contin\u00faa hasta que entendemos que los archivos han salido de nuestra ventana operativa y se ha creado una cadena sellada. En este momento, realizamos la operaci\u00f3n de deshidrataci\u00f3n y reemplazamos estos archivos con vac\u00edos. Por supuesto, no copiamos nada de nuevo al nivel de capacidad.<\/p>\n<p>Toda esta l\u00f3gica interesante se controla con solo una casilla en la interfaz: Copiar respaldos al almacenamiento de objetos tan pronto como se crean.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>\u00bfY para qu\u00e9 necesitamos este modo de copia? <\/h3>\n<p>\nSer\u00eda mejor reformular la pregunta: \u00bfde qu\u00e9 riesgos nos protege? \u00bfQu\u00e9 problema nos ayuda a resolver?<\/p>\n<p>La respuesta es obvia: por supuesto, es la recuperaci\u00f3n de datos. Si tenemos una copia completa de los datos locales en el almacenamiento de objetos, no importa qu\u00e9 suceda con nuestro entorno de producci\u00f3n, siempre podemos recuperar los datos de los archivos ubicados en un hipot\u00e9tico Amazon.<\/p>\n<p>Por lo tanto, vamos a repasar los posibles escenarios, desde el m\u00e1s simple hasta el m\u00e1s complejo.<\/p>\n<p>La aflicci\u00f3n m\u00e1s simple que puede caer sobre nosotros es la inaccesibilidad de uno de los archivos en la cadena de respaldo.<\/p>\n<p>Una historia m\u00e1s triste es que uno de los extensores de nuestro repositorio SOBR se ha roto.<\/p>\n<p>Peor a\u00fan es cuando todo el repositorio SOBR se vuelve inaccesible, pero el nivel de capacidad sigue funcionando.<br \/>\nY todo est\u00e1 realmente mal cuando se muere el servidor de respaldo y tu primer deseo es intentar llegar a la frontera canadiense en diez minutos.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAhora, analicemos cada situaci\u00f3n por separado.<\/p>\n<p>Cuando perdimos uno (bueno, incluso varios) archivos de copia de seguridad, solo necesitaremos iniciar el proceso de rescaneo del repositorio, y el archivo perdido ser\u00e1 reemplazado por un archivo vac\u00edo. Y con el proceso de rehidrataci\u00f3n (del que se habl\u00f3 al principio del art\u00edculo), el usuario podr\u00e1 descargar datos del almacenamiento en la nube a su almacenamiento local.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAhora la situaci\u00f3n es un poco m\u00e1s complicada. Supongamos que nuestro SOBR consta de dos extensiones que trabajan en modo de rendimiento, lo que significa que nuestros .vbk y .vib est\u00e1n distribuidos entre ellas de manera bastante desigual. Y en alg\u00fan momento, una de las extensiones se vuelve inaccesible, y el usuario necesita urgentemente recuperar la m\u00e1quina, parte de cuyos datos se encuentran precisamente en esta extensi\u00f3n. <\/p>\n<p>El usuario inicia el asistente de recuperaci\u00f3n, elige un punto al que desea restaurar, y el asistente, en el transcurso de su trabajo, llega a la conclusi\u00f3n de que no tiene todos los datos necesarios para la recuperaci\u00f3n localmente, por lo que necesita descargarlos del almacenamiento en la nube. Al mismo tiempo, los bloques que quedaron en el almacenamiento local no se descargar\u00e1n de la nube. Gracias al \u00edndice de restauraci\u00f3n (s\u00ed, tambi\u00e9n se mencion\u00f3 al principio del art\u00edculo).<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUna variante de este caso es que todo el repositorio SOBR se vuelva inaccesible. En este caso, no tenemos nada que copiar de los almacenes locales, y todos los bloques se descargan de la nube.<\/p>\n<p>Y la situaci\u00f3n m\u00e1s interesante: el servidor de copias de seguridad ha fallado. Aqu\u00ed hay dos opciones: el administrador es competente y realiz\u00f3 copias de seguridad de la configuraci\u00f3n, o el administrador es un malvado Pinocho y no hizo copia de seguridad de la configuraci\u00f3n.<\/p>\n<p>En el primer caso, ser\u00e1 suficiente simplemente desplegar una instalaci\u00f3n limpia de VBR en alg\u00fan lugar y restaurar su base desde la copia de seguridad con herramientas est\u00e1ndar. Al finalizar este proceso, todo volver\u00e1 a la normalidad. O ser\u00e1 restaurado seg\u00fan uno de los escenarios mencionados arriba.<\/p>\n<p>Pero si el administrador es su propio enemigo o si la copia de seguridad de la configuraci\u00f3n tambi\u00e9n ha sufrido una famosa calamidad, aqu\u00ed tampoco lo dejaremos a su suerte. Para este caso, hemos introducido un nuevo procedimiento llamado Import Object Storage. Este permite omitir el proceso de recreaci\u00f3n manual del repositorio SOBR y su vinculaci\u00f3n a un tirador de capacidad, seguido de un rescaneo, y simplemente agregar el almacenamiento de objetos en la interfaz de Veeam y ejecutar el procedimiento Import Storage Repository. Lo \u00fanico que puede interponerse entre usted y sus copias de seguridad es la solicitud de una contrase\u00f1a si sus copias de seguridad han sido cifradas.<\/p>\n<p>Con esto, terminamos sobre el Modo Copia y pasamos a<\/p>\n<h3>Modo Sellado<\/h3>\n<p>\nLa idea principal es que no pueden aparecer nuevas copias de seguridad en el extento seleccionado del repositorio SOBR. Hasta la versi\u00f3n 10, solo ten\u00edamos el Modo de Mantenimiento, donde se prohib\u00eda completamente cualquier trabajo con el repositorio. Una especie de modo hardcore para sacar el almacenamiento de la operaci\u00f3n, donde solo estaba disponible el bot\u00f3n Evacuar, que mov\u00eda las copias de seguridad a otro extento de una sola vez.<\/p>\n<p>El Modo Sellado es una especie de variante \"suave\": prohibimos crear nuevas copias de seguridad y eliminamos progresivamente las antiguas seg\u00fan la retenci\u00f3n seleccionada, pero en el proceso no perdemos la posibilidad de recuperarnos de los puntos almacenados. Es algo muy \u00fatil, especialmente cuando el hardware est\u00e1 cerca del final de su vida \u00fatil y necesita ser reemplazado, o simplemente debe liberarse para algo m\u00e1s importante, y no hay d\u00f3nde mover todo de una vez. O no se puede eliminar. <\/p>\n<p>Por lo tanto, el principio de funcionamiento es bastante simple: hay que prohibir todas las operaciones de escritura (aparecimiento de nuevos datos), dejando las de lectura (restauraciones) y eliminaci\u00f3n (retenci\u00f3n).<\/p>\n<p>Ambos modos se pueden usar simult\u00e1neamente, solo hay que tener en cuenta que el Mantenimiento tiene mayor prioridad.<\/p>\n<p>Como ejemplo, consideremos un SOBR que consta de dos extentos. Supongamos que durante los primeros cuatro d\u00edas se crearon copias de seguridad en modo Incremental Infinito Adelante, y luego sellamos el extento. Esto lleva a que iniciemos la creaci\u00f3n de un nuevo full activo en el segundo extento disponible. Si nuestra retenci\u00f3n es de cuatro, entonces, cuando toda la cadena situada en el extento sellado salga de su l\u00edmite, se eliminar\u00e1 sin remordimientos.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHay situaciones en las que la eliminaci\u00f3n ocurre antes. Por ejemplo, esto es un Forward incremental con full backups peri\u00f3dicos. Si durante los dos primeros d\u00edas realizamos full backups, y el jueves decidimos sellar el repositorio, entonces el viernes, cuando se cree un nuevo full, el archivo del lunes ser\u00e1 eliminado ya que hasta ese punto no tiene dependencias. Y ese punto no depende de nadie. Despu\u00e9s de esto, esperamos a que se creen cuatro puntos en el extente disponible y eliminamos los tres restantes, que no pueden ser eliminados independientemente unos de otros.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLas cosas son m\u00e1s sencillas con Reverse Incremental. En \u00e9l, los puntos m\u00e1s antiguos no dependen de nada y pueden ser eliminados sin problema. Por lo tanto, tan pronto como se cree un nuevo .vbk en un nuevo extente, los antiguos .vrb ser\u00e1n eliminados uno por uno.<\/p>\n<p>Por cierto, \u00bfpor qu\u00e9 creamos un nuevo .vbk cada vez? Si no lo hici\u00e9ramos y continu\u00e1ramos con la antigua cadena de incrementos, el viejo .vbk quedar\u00eda atascado indefinidamente en cualquier modo, impidiendo su eliminaci\u00f3n. Por lo tanto, se decidi\u00f3 que tan pronto como se sella un extente, creamos un full backup en un extente libre.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLas cosas son m\u00e1s complicadas con el capacity tier. <\/p>\n<p>Primero consideremos el modo copy. Supongamos que hemos creado backups activamente durante cuatro d\u00edas, y luego el capacity tier fue sellado. No eliminamos nada, sino que simplemente soportamos la retenci\u00f3n, despu\u00e9s de lo cual eliminamos los datos del capacity tier.<\/p>\n<p>Algo similar sucede en el modo move: esperamos la retenci\u00f3n, eliminamos lo antiguo en el almacenamiento local y eliminamos lo que est\u00e1 almacenado en el object storage.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn ejemplo interesante con Forever forward incremental. Establecemos la retenci\u00f3n en tres puntos y comenzamos a hacer backups desde el lunes, que se copian correctamente en la nube. Despu\u00e9s de sellar el almacenamiento, los backups contin\u00faan cre\u00e1ndose, manteniendo tres puntos, pero los datos almacenados en el capacity tier permanecen dependientes y no pueden ser eliminados. Por lo tanto, esperamos al jueves, cuando nuestro .vbk sale del rango de retenci\u00f3n, y solo entonces eliminamos toda la cadena guardada.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nY una peque\u00f1a aclaraci\u00f3n: todos los ejemplos aqu\u00ed se muestran con una sola m\u00e1quina. Si tienes varias en el backup, la retenci\u00f3n variar\u00e1 dependiendo de si se realiz\u00f3 un Active Full o no.<\/p>\n<p>Y con esto, en principio, es todo. As\u00ed que pasemos a la caracter\u00edstica m\u00e1s hardcore \u2014 <\/p>\n<h3>Inmutabilidad <\/h3>\n<p>\nAl igual que con los puntos anteriores, primero se debe mencionar qu\u00e9 problema resuelve esta funci\u00f3n. En cuanto exportamos nuestros respaldos a alg\u00fan lugar de almacenamiento, surge el deseo urgente de garantizar su conservaci\u00f3n, es decir, prohibir f\u00edsicamente su eliminaci\u00f3n y cualquier modificaci\u00f3n durante el per\u00edodo de retenci\u00f3n establecido. Esto incluye a los administradores, incluso bajo sus cuentas de superusuario. Esto permite protegerlos contra la corrupci\u00f3n accidental o intencionada. Quien trabaja con AWS puede haber encontrado una funci\u00f3n similar bajo el nombre de Object Lock.<\/p>\n<p>Ahora consideremos el modo en t\u00e9rminos generales, y luego profundizaremos en los detalles. En nuestro ejemplo, la Inmutabilidad estar\u00e1 habilitada para nuestro tiro de capacidad con una retenci\u00f3n de cuatro d\u00edas. Y el respaldo incluir\u00e1 el modo Copia.<\/p>\n<p>La inmutabilidad no interact\u00faa de ninguna manera con la retenci\u00f3n general. Por ejemplo, no agrega puntos adicionales ni nada por el estilo. Simplemente, durante cuatro d\u00edas, una persona no puede eliminar los archivos de respaldos. Si se realiza un respaldo el lunes, el archivo se podr\u00e1 eliminar \u00fanicamente el viernes.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTodos los conceptos previamente explicados de deshidrataci\u00f3n, \u00edndices y metadatos contin\u00faan funcionando exactamente igual. Pero con una condici\u00f3n: el bloqueo se aplica no solo a los datos, sino tambi\u00e9n a los metadatos. Esto se hace en caso de que un astuto atacante decida borrar nuestra base de metadatos y para que los bloques de datos no se conviertan en un revoltijo binario in\u00fatil.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nY ahora ha llegado el momento perfecto para explicar nuestra tecnolog\u00eda de generaci\u00f3n de bloques. O generaci\u00f3n de bloques. Para ello, consideremos la situaci\u00f3n que llev\u00f3 a su aparici\u00f3n.<\/p>\n<p>Tomemos una l\u00ednea de tiempo de seis d\u00edas y marquemos en la parte inferior el tiempo de expiraci\u00f3n esperado de la inmutabilidad. Creamos, en el primer d\u00eda, un archivo que consiste en un bloque de datos a y sus metadatos. Si la inmutabilidad se establece en tres d\u00edas, es l\u00f3gico suponer que en el cuarto d\u00eda los datos ser\u00e1n desbloqueados y eliminados. En el segundo d\u00eda, a\u00f1adiremos un nuevo file2, que consiste en el bloque b con las mismas configuraciones. El bloque a a\u00fan deber\u00eda ser eliminado en el cuarto d\u00eda. Pero en el tercer d\u00eda sucede lo terrible: se crea un archivo File3, que consiste en un nuevo bloque d y un enlace al antiguo bloque a. Esto significa que para el bloque a su bandera de inmutabilidad debe ser reinstaurada a un nuevo plazo, que se desplaza al sexto d\u00eda. Y aqu\u00ed surge un problema: en las copias de seguridad reales, tales bloques se generan en gran cantidad. Y para extender su periodo de inmutabilidad, hay que realizar una gran cantidad de solicitudes cada vez. De hecho, esto se convierte en un proceso casi infinito a diario, ya que con gran probabilidad encontraremos enormes lotes de bloques desduplicados con cada copia. \u00bfY qu\u00e9 significa una gran cantidad de solicitudes para los proveedores de almacenamiento de objetos? \u00a1Correcto! Una enorme factura al final del mes.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nY para no generar de la nada grandes costos para nuestros valiosos clientes, se ide\u00f3 el mecanismo de generaci\u00f3n de bloques. Este es un periodo adicional que a\u00f1adimos al periodo de inmutabilidad establecido. En el ejemplo a continuaci\u00f3n, este periodo es de dos d\u00edas. Pero esto es solo un ejemplo. En realidad, se utiliza una f\u00f3rmula propia que proporciona aproximadamente diez d\u00edas adicionales con un bloqueo mensual. <\/p>\n<p>Continuaremos analizando la misma situaci\u00f3n, pero ahora con la generaci\u00f3n de bloques. Creamos en el primer d\u00eda file1 a partir del bloque a y los metadatos. Acumulamos el per\u00edodo de generaciones e inmutabilidad, lo que significa que la posibilidad de eliminar el archivo ser\u00e1 en el sexto d\u00eda. Si en el segundo d\u00eda creamos File2, que consiste en el bloque b y un enlace al bloque a, entonces no sucede nada respecto a la fecha prevista de eliminaci\u00f3n. Se mantiene en el sexto d\u00eda. Con esto estamos tratando de ahorrar dinero en la cantidad de solicitudes. La \u00fanica situaci\u00f3n en la que el plazo puede ser trasladado es si el per\u00edodo de generaci\u00f3n ha expirado. Es decir, si en el tercer d\u00eda el nuevo File3 contiene un enlace al bloque a, se a\u00f1adir\u00e1 la generaci\u00f3n 2 ya que la Gen1 ya ha expirado. La fecha de eliminaci\u00f3n esperada del bloque a se trasladar\u00e1 al octavo d\u00eda. Esto nos permite reducir dr\u00e1sticamente la cantidad de solicitudes para extender la vida \u00fatil de los bloques deduplicados, lo que ahorra una gran cantidad de dinero a los clientes.<\/p>\n<p><img decoding=\"async\" alt=\"\u00bfQu\u00e9 ha cambiado en Capacity Tier desde que Veeam se convirti\u00f3 en v10?\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa tecnolog\u00eda en s\u00ed est\u00e1 disponible para los usuarios de S3 y hardware compatible con S3, cuyos fabricantes garantizan que su implementaci\u00f3n no difiere de la de Amazon. De aqu\u00ed la respuesta a la pregunta leg\u00edtima de por qu\u00e9 no se admite Azure: ellos tienen una funci\u00f3n similar, pero funciona a nivel de contenedores, no de objetos individuales. Por cierto, en Amazon hay modo de bloqueo de objeto en dos modalidades: cumplimiento y gobernanza. En el segundo caso, permanece la posibilidad de que el superadmin y root de todos los root, a pesar del bloqueo de objeto, elimine los datos. En caso de cumplimiento, todo queda sellado de manera irrevocable y ninguna copia de seguridad puede ser eliminada por nadie. Ni siquiera por los administradores de Amazon (seg\u00fan sus declaraciones oficiales). Soportamos espec\u00edficamente este modo.<\/p>\n<p>\nY, como es tradicional, un poco de enlaces \u00fatiles:<\/p>\n<ul>\n<li>Sobre <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Generaci\u00f3n de Bloques<\/a><\/noindex> en todos los detalles.<\/li>\n<li>Toda la informaci\u00f3n sobre <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> de la mejor manera<\/li>\n<li>A <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/a><\/noindex> en detalles<\/li>\n<\/ul>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/505818\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84810,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00bfQu\u00e9 ha cambiado en el Capacity Tier desde que Veeam se convirti\u00f3 en v10 | ProHoster","description":"El Capacity Tier (o como lo llamamos internamente en Veeam \u2014 captir) apareci\u00f3 a\u00fan en los tiempos de Veeam Backup and Replication 9.5 Update 4 bajo el nombre de Archive Tier.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster","og:description":"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-10T23:42:41+00:00","article:modified_time":"2020-06-10T23:42:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84809","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:49:54","updated":"2022-09-29 08:38:47","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}