Si usas GNU/Linux en tu día a día pero tienes Windows en una máquina virtual por si las moscas, esto también es un problema aunque no uses Windows más que una o dos veces al año. Por ejemplo, si usas Windows para entrar en la típica página de la administración porque no has sido capaz de configurar un navegador de forma que funcione correctamente, vas a tener que tener un sistema compatible pero actualizado. No quieres usar un sistema desactualizado, sin parches, etc., para cosas tan sensibles como tu declaración de la renta o gestionar cosas con la Seguridad Social. Aunque creas que te da igual, no te da igual, y no quieres hacerlo.

Para poder llevar a cabo este proceso tu ordenador físico tiene que cumplir con los requisitos de hardware de Windows 11 en términos de microprocesador, módulo de seguridad TPM, y demás. La virtualización es un proceso que comparte dispositivos reales de la máquina física entre distintos sistemas operativos: uno anfitrión, que es el que está instalado sobre la máquina física, y los distintos sistemas operativos huéspedes, instalados en las máquinas virtuales.

Aunque pudiese haber productos que, además de virtualización, tuviesen capadidades de emulación para exponer un chip TPM realizado por software, o para que Windows 11 percibiese un microprocesador de una serie más moderna que el tuyo, VirtualBox no es uno de ellos.

Por lo tanto, utilizar VirtualBox no te va a servir para instalar Windows 11 en un PC que no esté soportado.

Al igual que actualizar un ordenador a Windows 11, actualizar una máquina virtual tiene sus curvas, sus terraplenes y sus trucos: si cambiamos el hardware virtual de nuestra máquina virtual, nuestra licencia de Windows 10 no será válida, y tendremos que comprar una licencia de Windows 11. No podemos crear otra máquina virtual, instalar Windows 11 y usarlo, porque no tendremos licencia de Windows para ese hardware. Incluso si creamos la máquina virtual con los mismos identificadores de hardware, sospecho que al no haber cambiado de Windows 10 a Windows 11 de forma controlada podríamos tener algún problema de licencia porque la licencia vinculada a esos identificadores de hardware es de Windows 10.

Por si fuera poco, VirtualBox no se caracteriza por ofrecer una experiencia de virtualización de Windows 11 adecuada, ni por facilitar la actualización desde Windows 10:

1. Hasta hace relativamente pocos telediarios, las máquinas virtuales de VirtualBox tenían una definición equivalente a un PC de hace 20 años, y no exagero: BIOS, esquema de particiones MBR, nada que se parezca a un chip TPM es ofrecido a la máquina virtual, el arranque seguro es ciencia-ficción y la EFI “sólo es válida para sistemas operativos especiales”.
2. Por las razones arriba expuestas, estas máquinas no soportan Windows 11. Para usar Windows 11 en estas máquinas debías usar el proceso existente para decirle a Windows que no comprobase sus requisitos de hardware. Esto cae en un terreno gris donde Microsoft no termina de posicionarse, pero siempre ha barajado no permitir que dichos PC recibiesen actualizaciones.
3. En VirtualBox 7, como quien dice, anteayer, Oracle por fin implementó todas las características que requiere Windows 11 de forma nativa y ya permite definir una máquina virtual con EFI, arranque seguro, TPM 2.0 y todas esas otras características.
4. En una máquina virtual existente, activar esas características permitiría, en teoría, ejecutar el proceso de actualización a Windows 11 sin perder la licencia ni tener que hacer arcanos de terminal ni editar ficheros a mano.
5. Sin embargo, activar la EFI, TPM y arranque seguro en nuestra máquina virtual existente la dejará aparentemente inservible, porque no arrancará.

No es un problema tan descabellado, tiene su sentido, la causa del problema es trivial y, por suerte, tiene fácil solución. El problema es que la máquina no encuentra el sistema operativo: el disco donde está Windows 10 es un disco formateado con un esquema de particiones MBR, típico de la época de los PC con BIOS, mientras que los PC con EFI espera discos formateados con esquema de particiones GPT.

Así pues, para poder activar la EFI hay que convertir la tabla de particiones de un disco desde MBR a GPT. Para ello y como se discute en el enlace anterior, Microsoft proporciona un programa llamado mbr2gpt.exe. Afortunadamente, todas las instalaciones de Windows 10 que conserven su partición de recuperación lo tienen disponible, y las instalaciones hechas en VirtualBox no son una excepción. Además, y por si las moscas, ese programa está incluido en todas las imágenes de DVD o de memoria USB que usaríamos para reparar, actualizar o restaurar el sistema.

Esto es lo que hay que hacer específicamente en Virtual Box:

• Actualiza tu instalación de Windows 10 hasta la última actualización disponible.

• Realiza una copia de seguridad de tus ficheros, por si la conversión desde MBR a GPT fallase por alguna razón y debieras reinstalar Windows 10.

• Recuerda: tu licencia está vinculada a Windows 10. Hasta que no tengas un sistema actualizado a Windows 11 y con Windows 11 activado, creo que no puedes formatear e instalar Windows 11 desde cero.

• Descarga el programa de creación de medios de instalación de Microsoft para crear dos medios de instalación en formato ISO: Windows 10.iso y Windows 11.iso.

• Reinicia tu sistema operativo en modo recuperación pulsando la tecla de mayúsculas mientras pinchas en el botón Reiniciar de Windows 10

• Alternativamente, utiliza cualquiera de las ISO que acabas de descargar para reparar el sistema.

La ISO de Windows 11 ofrece opciones para reparar el sistema, igual que la partición de recuperación de Windows 10.

• En este entorno, abre un intérprete de comandos (Troubleshoot > Advanced Options > Command Prompt o algo como Solución de Problemas > Opciones Avanzadas > Intérprete de Comandos) y ejecuta los comandos siguientes:

  mbr32gpt /validate

Comando para validar tu unidad de disco. Si todo va bien, la salida del programa terminará con MBR2GPT: Validation completed successfully.

mbr2gpt /convert

Comando para convertir tu unidad de disco desde MBR a GPT. Si todo va bien, la salida del programa terminará con MBR2GPT: Conversion completed successfullyMBR2GPT: Update WinRE config fileMBR2GPT: Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!

Diferentes pantallas del proceso explicado en los puntos anteriores, donde podemos ver el aspecto del proceso de recuperación y la salida de los comandos.

• Apaga la máquina virtual de forma ordenada y, en VirtualBox, cambia la configuración para que EFI, Arranque Seguro (Secure Boot), el chip TMP 2.0 y la aceleración de gráficos en 3D estén activadas en el siguiente arranque.

Activando las opciones EFI y Secure Boot.Activando la aceleración 3D, y dotando a la máquina de suficiente memoria de vídeo (256 MB, que es el máximo)

• Arranca la máquina virtual. El sistema debería arrancar perfectamente y funcionar como si nada.
• Actualiza Windows 10 una vez más.

Windows seguirá diciendo que tu sistema no es compatible con Windows 11, y sólo obtendrás actualizaciones de Windows 10. Esto no es cierto gracias a los cambios que hemos llevado a cabo en la máquina: mi sospecha es que el programa de compatibilidad que Microsoft ha escrito tiene una base de datos de fabricantes reconocidos que no está preparado para máquinas virtuales. Pero esto no es un problema, porque tenemos una ISO de Windows 11 y podremos iniciar el proceso pese a todo.

• Monta la ISO de Windows 11 en la unidad de DVD que tiene tu máquina virtual.
• Ábrela con el Explorador de Ficheros y ejecuta el programa setup.exe.

Programa de instalación de Windows 11, en el Explorador de Ficheros de Windows 10

• Selecciona las opciones adecuadas para conservar tus ficheros y aplicaciones (o no), y actualizar el sistema.

Si todo te ha ido igual de bien que a mí, deberías tener una máquina virtual con Windows 11 donde todos los requisitos están cumplidos, la activación del sistema es correcta y está vinculada a tu cuenta de Microsoft. Detalle de la máquina virtual Windows 11 mostrando los detalles del chip TPM que le es ofrecido. Es hora de actualizarla una última vez para recibir actualizaciones específicas de Windows 11, crear una copia de seguridad de acuerdo a tu propia estrategia, y dedicarte a cosas más productivas.

Era genial.

Entonces, llegó Spotify, primero como inversor, y luego comprando Anchor. Al poco tiempo, todas las características sociales y el funcionamiento que comentaba arriba, como la emisora, desaparecieron del producto y nos quedamos con una plataforma de podcasting solvente, y nada más.

No voy a dar cuenta en detalle del proceso de enmierdificación de Spotify en este artículo, sino que me voy a limitar a decir que no estoy cómodo en esa plataforma desde hace tiempo, y he decidido autoalojar en casa mi propio podcast. El soporte a mi podcast me lo da ahora Castopod, una plataforma de podcasting libre y de código abierto que, además, ofrece integración con el fediverso mediante Activity Pub y soporte a múltiples características del podcasting 2.0, como la posibilidad de dejar comentarios desde tu propia aplicación de escucha de podcasts entre otras cosas.

Vamos a ver cómo se migra un podcast a Castopod. En este artículo se trata de Spotify, pero el proceso va a ser muy similar en cualquier otro caso.

Obtén Castopod

Castopod está disponible para instalar en tu propio servidor, que puede ser una VPS o una máquina sencilla conectada a internet, o puedes contratarlo en varios proveedores especializados. En castopod.org tienes acceso a información acerca de todas las opciones. Yo lo he instalado en un mini PC, en mi casa, usando Docker y NGINX como proxy inverso. Publicaré algo al respecto en lo sucesivo, pero hoy me voy a centrar en el proceso de salida de Spotify.

Opcional: obtén tu propio dominio y, si es posible, una CDN

Si lo vas a instalar en tu casa, vas a necesitar un dominio. Si lo usas ofrecido por alguno de los proveedores, probablemente puedas usar un subdominio proporcionado por ellos.

En cualquier caso, como un podcast sirve archivos de cierto peso, es buena idea contratar un servicio que te ofrezca una red de distribución de contenidos (CDN) con presencia en múltiples geografías: actuará de caché, relajando los requisitos de ancho de banda de tu proveedor, y además acelerará el acceso a tu podcast desde geografías lejanas. Personalmente, uso la cuenta gratuita de Cloudflare para los dos asuntos: dominio y CDN.

Importa tu Podcast en Castopod

Una vez Castopod está funcionando en tu servidor, es hora de importar tu podcast en Castopod. Esto se hace indicando la dirección del feed RSS a Castopod en su panel de control, así como el nombre de usuario en el fediverso, la categoría y el idioma del contenido.

![)Formulario de importación de un podcast en Castopod Es importante tener en cuenta que Castopod va a reinterpretar todo el feed y a validarlo. Uno de los problemas que tuve derivados de este aspecto es que, si a alguno de tus episodios le faltan las notas (el contenido del campo <description />), el proceso va a fallar, tendrás que corregir el episodio en concreto, esperar a que Spotify republique tu feed, y reanudar el proceso donde se interrumpió. En mi caso, llevó unos cuantos intentos:

Opcional: activa las estadísticas OP3

Las estadísticas que ofrece Castopod por defecto son bastante buenas, pero si te interesa la iniciativa Open Podcast Prefix Project, OP3, es un buen momento para unirte a ella activando las estadísticas con un sólo click en el formulario de edición de tu podcast.

Redirige tu antiguo feed al nuevo, permanentemente

Éste es el paso más sencillo, y más crítico. En Spotify para Podcasters, en el panel de edición de tu podcast, encontrarás un campo de texto para introducir un nuevo feed al que redirigir el antiguo. Esta redirección se implementa mediante un código de estado del protocolo HTTP, 301, que indica a los clientes, índices, buscadores y directorios de podcasting que el feed se ha mudado y nunca volverá a Spotify. En el cuerpo de la respuesta que acompaña a ese estado de redirección permanente 301 está la dirección del nuevo feed. El comportamiento esperado para clientes HTTP (cualquier aplicación o servicio que quiera acceder al feed) cuando reciben una respuesta con estado 301 es actualizar sus registros a la nueva dirección y no volver a intentar acceder a la antigua nunca más.

A partir de este momento, y en un tiempo indeterminado, todos tus suscriptores empezarán a recibir contenido por el feed nuevo, y si tienes la misma experiencia que yo, de una forma totalmente transparente.

⚠️ Cuando esto pase, perderás el control de tu podcast en Spotify para Podcasters

Esto es algo de lo que Spotify no te avisa claramente, pero cuando Spotify perciba que el podcast ya no está bajo su control, perderás acceso a funciones de edición del mismo, e incluso a la posibilidad de borrar los datos del mismo en Spotify.

Aún cuando veas que esto está pasando, no borres aún tu cuenta de Spotify para Podcasters: si algún rezagado no ha recibido la instrucción de redirección y borras tu cuenta, se borra la redirección, con lo cual podrías perder oyentes. Personalmente, yo voy a borrarla pasado un mes.

⚠️ Escoge cuidadosamente el momento de hacer esto si alojas tu nuevo podcast en tu casa.

En el momento en el que actives la redirección en Spotify, servicios de directorio que probablemente no sepas que estaban indexando tu feed recibirán las coordenadas del feed nuevo. Estos servicios de directorio usan procesos tipo arañas (mala traducción de web crawlers) para recorrer el feed y reindexarlo todo.

El cambio desde Spotify para Podcasters a Castopod es muy profundo. En términos de la propia estructura del feed, de dónde están alojados los ficheros, y del nombre de los mismos, el efecto es que todos estos procesos perciben tu podcast como una reedición completa. Como decimos en España, a este feed no lo reconoce ni su padre. Esto hace que todos estos actores invaliden todos los datos previos y lo recorran todo de nuevo, descargando todos y cada uno de tus episodios, metadatos, imágenes… todo. Y en este momento, aunque tengas CDN, su caché todavía está vacía, por lo que todas las peticiones van a ir directas a tu casa.

Estos servicios tienen una capacidad de cómputo y de red inmensamente mayor que la de tu casa, por lo que todos* ataquen tu feed a la vez*, tu conexión a internet va a experimentar un pico de tráfico de subida muy significativo, que puede afectar a tu conectividad, especialmente si hay alguien trabajando desde casa.

Por eso, mejor hazlo por la noche. No seas como yo 😅

Solicita el traspaso de tu Podcast a tu propiedad en los distintos directorios (que te interesen)

Esto es importante.

Me voy a centrar en Apple Podcasts, pero es fácil entender que esto deberías hacerlo allá en donde te interese tener presencia, en tu caso particular.

Acabas de redirigir tu feed a Castopod, tu conexión a internet en casa las ha pasado canutas, y has tenido que dar explicaciones a tu mujer e hijos de por qué internet iba como una patata, pero todo ha vuelto a su cauce normal, todo funciona y los primeros oyentes que sabían que ibas a cambiar esto te felicitan, te dicen que las descargas van más lentas…

Sin embargo, los directorios de podcasting como Apple Podcasts no te tienen registrado como el autor o el responsable del mismo a la hora de enviarte alertas y avisos con respecto a tu podcast. Situaciones en las que te podrías ver involucrado y que te interesaría resolver con Apple, como una potencial violación de los Términos y Condiciones de su servicios de directorio, no te serán notificadas.

Por otro lado, tampoco tienes control sobre tu podcast en Spotify para Podcasters, que es a donde Apple enviaría este tipo de mensajes en caso de conflicto. Spotify te ha dado la patada en cuanto la redirección se ha vuelto efectiva.

Estás en tierra de nadie.

Es hora de ponerse en contacto con Apple Podcasts Connect y solicitar que te den control sobre tu podcast.

Para eso, ármate con tu fluidez en el idioma de Shakespeare, porque creo que el formulario no se ofrece en Español, y haz lo siguiente (efectivo en Mayo de 2024):

1. Entra en Apple Podcasts Connect, o regístrate si no tienes cuenta.

2. Abajo de todo, selecciona “Contact Us”

3. En el formulario que aparece, rellena tus datos y selecciona como tema de consulta “Missing Podcast(s)” dentro de “Content Management”. Tendrás que introducir los siguientes datos:

4. El título del podcast ("Podamigos del cocido")

5. El id del podcast. Entiendo que se trata de los números al final en la URL del podcast en Apple Podcasts: “id817487481”.

6. La URL completa a la página del podcast en Apple Podcasts.

7. La URL del nuevo feed.

8. En el cuerpo del mensaje, indica que has migrado tu podcast desde Spotify a otro hosting, indica también la del anterior por si acaso el operador que te atienda todavía tiene el antiguo feed en sus cachés, y pide instrucciones como te gustaría que te las pidiesen a ti.

Este fue el mensaje enviado, nada fuera de lo común:

Good afternoon.

I am writing as the author of the show “sobre la marcha”, which was previously hosted on Spotify for Podcasters. I recently re-hosted the show on my own hosting server, and I would like to claim ownership and be able to manage it under my Apple Podcasts Connect dashboard. I hope this is the right method / channel to request so.

Looking forward to hearing from you,

~Gabriel Viso Carrera

PS – before today, the show’s feed was “https://anchor.fm/s/dd4f78/podcast/rss". As part of the migration, it has been placed a 301 permanent redirection to the feed I filled in this form; please take it into consideration of you see that the redirection hasn’t been followed in your systems yet. Please note that no further episodes will be appearing in such feed.

Te enviarán un correo en un plazo de un par de días, pidiéndote más datos (como el ID de tu cuenta en Apple Podcasts Connect), y dándote un código numérico que deberás introducir en algún campo del feed. Por ejemplo, mí me dieron como opciones el campo de <copyright />, <keyword /> o <verification />.

En negrita los aspectos clave que nos piden en esta respuesta de ejemplo, que es lo que me contestaron a mí con algunas cosas cambiadas.

Hello Gabriel,

Thanks for reaching out to us. I hope you’re doing well.

To get access to the show in Apple Podcasts Connect, we can transfer the ownership of it to your account.

To transfer ownership, enter the six-digit authorization code “381234” in the verification, keyword, or copyright fields of your RSS feed.

You can update the six-digit authorization code on your hosting provider’s platform or edit the metadata tags in your RSS feed. If you need assistance with this update, contact your hosting provider. We’ll review your request after we receive your reply.

When you reply, tell us where you entered the authorization code so we can find it and include the Account ID of your Apple Podcasts Connect account.

You can locate the Account ID on the Details pane in the Account section in Apple Podcasts Connect.

Example Account ID: 12a345bc6-d7ef-8901-2ghi-j3k4lm56n7o8

If you have additional questions related to this request, please reference case number 384791872432.

Best regards,

Mary Jane Apple Inc.

El feed que genera Castopod no tiene campo <verification />, pero como añadir campos a medida es sencillísimo, es la solución ideal porque nadie recibirá ese cambio de forma visible. Ve al panel de control de edición de tu podcast, y abajo de todo encontrarás un campo donde poder poner el campo extra:

Salva los cambios en tu podcast, verifica que en unos segundos, el feed tiene el mencionado campo dentro del objeto <channel />, y contesta a Apple con los datos que te han solicitado, que incluyen dónde pueden encontrar el valor en cuestión.

Good morning, Mary Jane.

Thanks for your prompt reply. As requested:My Podcasts Connect Account ID is 12a345bc6-d7ef-8901-2ghi-j3k4lm56n7o8.I’ve just included the code you provided in the tag of my feed, inside the <channel /> element:

<rss version=“2.0”> <channel> … ** <verification>381234</verification>** … </channel> </rss>

Thank you for your help and kind regards, ~Gabriel

Cuando recibas la confirmación y al cabo de un tiempo prudencial que te indicarán, deberías poder controlar tu relación con el directorio de Apple Podcasts tú mismo.

No tengas prisa en borrar cosas

En realidad ya está, pero es importante que no corras a Spotify y a tu feed a borrar cosas y deshacer cambios, porque puedes revertir el proceso sin querer.

1. Como comentaba en el apartado de la redirección permamente, no tengas demasiada prisa en borrar tu cuenta de Spotify, porque podrías perder oyentes.
2. Aún cuando ya tengas tu podcast en Apple Podcasts Connect, no corras a editar tu podcast en Castopod para retirar el campo de verificación. Ten en cuenta que el directorio de podcasts de Apple tienen páginas en todo el mundo, y no nos interesa que, por alguna razón, alguna versión antigua del feed se haya quedado en algún sitio y reasignen tu podcast a Spotify. Deja ese campo de verificación en tu feed el tiempo que te parezca oportuno.

Pues ya estaría

Hasta aquí mi experiencia. Espero que te resulte útil e interesante.

Pika Backup es una solución de copias de seguridad para GNU/Linux que, sin dejar de ser extremadamente sencilla de utilizar, proporciona características muy interesantes y es muy eficiente. Está basado en Borg Backup, un sistema que crea copias de seguridad comprimidas, cifradas, y que además detecta y elimina duplicados en la copia de seguridad.

Las características de Pika Backup que me han convencido han sido las siguientes:

• Permite realizar copias de seguridad a discos USB y a cualquier directorio remoto, y soporta Borg en el lado del servidor:

• Directorio “tonto”: cualquier directorio en donde tengas acceso local (por ejemplo, servicios tipo Drop Box o One Drive), y a localizaciones remotas “tradicionales” como servidores de ficheros FTP, o carpetas compartidas en red.

• En sí, esto ya es muy potente y versátil.

• Servicio remoto con soporte para Borg Backup, si quieres mejor rendimiento. Esto no es más que un servidor donde el ejecutable borg esté instalado, y al que tengas acceso por ssh. Una Raspberry Pi con el paquete borgbackup instalado y un disco duro enchufado por USB es suficiente para tener copias de seguridad en red en casa, con rendimiento mejorado.

• No hay por qué saber usar Borg; Pika Backup lo hace todo por ti, tanto en tu ordenador de trabajo como en tu servidor de copia de seguridad.

• Más adelante os cuento por qué esto es tan ventajoso.

• Permite tener más de una tarea de copia de seguridad configuradas sobre el mismo conjunto de datos, para poder tener tu copia de seguridad en varios lugares. Por ejemplo, en un servidor en red, donde ejecutas la copia de seguridad de forma programada, y en un disco externo por USB, donde ejecutas la copia manualmente, cuando te parece bien.

• Esto permite desarrollar una **estrategia 3:2:1 **sin salir de Pika Backup.

💡 Una estrategia 3:2:1 significa que deberíamos tener 3 réplicas de los datos, 2 de las cuales serían las copias de seguridad, ubicadas en sistemas almacenamiento diferentes, para 1 conjunto de datos en particular.

De esa forma, siempre nos protegemos en caso de daño físico tanto a nuestra estación de trabajo como a discos de las copias, siendo extremadamente difícil que fallen las tres réplicas a la vez.

• Es amigable para portátiles, porque detecta si el ordenador está conectado a la corriente, y si no lo está, ni siquiera intenta realizar la tarea de copia de seguridad programada.
• Proporciona filtros predefinidos para excluir de la copia de seguridad máquinas virtuales, contenedores, cachés y aplicaciones flatpak instaladas en el directorio de usuario. Esto simplifica bastante la configuración, aunque si no es suficiente, se pueden añador desde ficheros y carpetas individuales, hasta filtros basados en nombres de fichero y en expresiones regulares.
• Las copias de seguridad se pueden programar (hay reglas horarias, diarias, semanales, mensuales o anuales), y permite especificar el día y la hora 🎉. Esto parece baladí, pero si sabes que, por ejemplo, los domingos por la tarde el portátil va a estar en el escritorio con tareas de mantenimiento como actualizar el sistema, con sólo dejarlo enchufado la copia de seguridad se va a realizar automáticamente.

De por sí, las funcionalidades que proporciona Pika Backup en su interfaz gráfico son ya suficientes para convencerme; sobre todo el hecho de poder tener todas las copias de seguridad de mi estrategia 3:2:1 en la misma aplicación. Pero donde lo remata es en el aspecto de ser un cliente de Borg, y por lo tanto soportar servidores con Borg, para acelerar todas las operaciones de copia y restauración, y en especial la verificación de las copias de seguridad.

En general, hay que verificar las copias de seguridad, al menos cada cierto tiempo. Con ello nos aseguramos de que los archivos se han generado y almacenado correctamente, y que no hay nada corrupto. Y esto es un proceso que, si se hace en red, es muy costoso: Pika debería descargarse un trozo de la copia de seguridad desde el servidor de red, verificar su integridad, buscar el siguiente trozo, y así… hasta 130 GB en mi caso. He presenciado verificaciones de integridad hechas así que tardaron 20 horas. Y así es como se hace cuando Pika Backup deposita las copias de seguridad en un directorio de red, “tonto”, es decir, sin Borg.

Con Borg, la cosa cambia. El hecho de que Pika Backup esté basado en Borg Backup y, a todos los efectos, que sea un cliente de Borg, acelera el proceso de una forma drástica. Según la documentación de Borg, el proceso del lado del servidor realiza las operaciones de gestión de almacenamiento completas cuando se hace la copia de seguridad, y la verificación en sí. Esto incrementa el rendimiento sensiblemente, porque elimina el trasiego de datos por la red, y reduce el tiempo de verificación de una copia tan masiva como 130 GB de 20 horas a unos 35 minutos.

En general estoy muy contento con el cambio, ya que me permite realizar las cosas más eficientemente, utilizar mejor los recursos, y sobre todo, sobre todísimo, poder realizar todas las copias de seguridad de mi estrategia con la misma aplicación y de forma sencilla.

Extremadamente recomendable.

¿Cómo se compara Pika Backup con Déjà Dup?

Déjà Dup es una solución basada en duplicity que se ofrece, tradicionalmente, como parte del entorno de escritorio Gnome. Realiza copias de seguridad cifradas, incrementales, y las almacena en un formato de archivo comprimido que, independientemente de dónde almacenes estos archivos, preserva los permisos de los ficheros en tu máquina.

• Soporta discos externos y todo tipo de almacenamiento remoto –la lista completa se puede consultar en la documentación de duplicity, pero sólo soporta una única configuración para tu copia de seguridad. La copia de seguridad que configures, es única y a un sólo destino. Esto dificulta el realizar una estrategia de copias de seguridad robusta, 3:2:1, con la misma herramienta.
• Por otro lado, el sistema de copias de seguridad no tiene parte servidora, como la tiene Borg (y la aprovecha Pika Backup al ser éste un cliente gráfico y versátil de Borg); esto quiere decir que la verificación y el almacenamiento sea mucho más lento.
• No está bien pensado para portátiles, si es que han pensado en portátiles en absoluto.
• No permite escoger el día o la hora de las copias de seguridad programada. Si cuando configuras Déjà Dup las copias semanales caen en miércoles por el artículo 33, moverlas al domingo no es nada intuitivo, si es que el posible. Y, si cuando entra la copia de seguridad, te tienes que ir con tu portátil, el proceso se va a quedar por ahí medio enganchado.
• Las copias de seguridad programadas siempre se intentan realizar, estés funcionando en batería, sin red, o lo que sea. Esto consume energía y genera errores de forma innecesaria.

Todo este tipo de cosas hacen que Déjà Dup se vaya quedando atrás. Si bien es igual de sencillo de usar que Pika Backup, el ritmo al que añaden el tipo de funcionalidades que me afectan más es bastante bajo, casi diría que cae en la apatía, y estas cosas van desluciendo al producto poco a poco.

Comentarios previos

Antonio, el 8 de mayo de 2024 , comentó:

Gabriel, estupendo artículo muy interesante para los que tenemos que hacer respaldos de los archivos regularmente. Recomiendas alguno para macOS?. Gracias

Gabriel Viso Carrera, el 8 de mayo de 2024, respondió:

Para macOS solo tengo experiencia con Time Machine y Super Duper. Los dos hacen bien su tarea.

No descarto probar Vorta, que está basado en Borg Backup, igual que Pika Backup. Si quieres echarle un vistazo ve a https://vorta.borgbase.com