Documentación

Índice

Introducción a HD Lorean

hd-lorean-title.png

HD Lorean no es sólo una aplicación de copias de seguridad totalmente integrada en Linux que te permitirá ver cualquier documento que elijas en cualquier instante de tiempo. No. Es mucho más. Deja que te descubramos algunos de sus usos.

Comenzar es fácil

Por defecto, HD Lorean ya sabe qué debe vigilar, HD Lorean guardará información importante para ti y tu sistema. Tan sólo deberás indicarle dónde debe guardar las copias de seguridad.

Vuelve al pasado

Utilizando tu explorador de siempre, podrás buscar archivos que perdiste o borraste hace mucho tiempo y comprobar el aspecto exacto que tenían en ese instante. Busca utilizando tu propia clasificación de archivos para que te resulte más natural. Con un clic en el botón Traer Al Presente, HD Lorean recuperará los archivos seleccionados haciéndolos visibles en el presente. HD Lorean es capaz de recuperar archivos individuales, carpetas enteras y archivos específicos indicados por programas de terceros.

Cómo funciona HD Lorean

HD Lorean supervisa automáticamente los cambios de los archivos aunque también puedes indicar manualmente cada cuánto deseas que se realice una copia de seguridad.

¿Dónde deseas guardar las copias de seguridad?

Selecciona prácticamente cualquier tipo de soporte para tus copias de seguridad, ya sea externa o no: un disco duro, una memoria USB, una partición, un dispositivo o carpeta en red… Da igual qué soporte elijas, HD Lorean sabe cómo manejar cualquiera de ellos y si uno no está disponible en un momento dado, la copia de seguridad se almacenará provisialmente en tu disco duro hasta que el soporte vuelva a estar disponible.

Diferentes equipos, una misma unidad

HD Lorean crea una carpeta dónde guardará las copias de seguridad, dentro de esta creará una por equipo y dentro de cada una, otra por usuario permitiendo así que todos los usuarios de cualquier equipo trabajen con la misma unidad.

¿Cómo es una copia de seguridad?

HD Lorean realiza una primera copia de seguridad sin compresión y a partir de allí realiza copias incrementales, es decir, que sólo guarda los cambios ocurridos desde la última vez. Esto no garantiza que tu disco duro no se llene nunca, pero lo hará mucho más lentamente que si siempre se copiara absolutamente todo.

Carpe Diem: vive el momento

Día a día, hora a hora o cuando tú decidas se realiza automáticamente una copia de seguridad de tu información más importante.

No alteres tu ritmo de vida

Has terminado de trabajar. Tienes que apagar el equipo e irte pero HD Lorean está realizando una copia de seguridad. No te preocupes, simplemente apaga: HD Lorean pausará la copia de seguridad hasta que vuelvas a encender el equipo.

Copia lo que quieras

En primera instancia, HD Lorean guarda una copia de los archivos de tu cuenta, pero si deseas que esto no sea así, tan sólo accede al menú Archivos Excluidos y añade tanto tipos de archivos que no quieras guardar como archivos expresos que quieras que queden fuera de la copia de seguridad.

¿Y si se acaba el espacio?

No pasa absolutamente nada, HD Lorean puede retomar sus tareas en otro disco duro o bien puede ayudarte a crear una colección de DVDs o CDs dónde guardar las copias de seguridad más antiguas.

Descubre una nueva dimensión temporal

Por qué tener una carpeta para las fotos de verano de este año, otra para las del anterior, otra para el de hace dos años, etc. Mejor tener una sola carpeta fotos de verano con las más recientes y poder consultarla en distintos momentos del tiempo. HD Lorean permite asociar un periodo de caducidad al contenido de una carpeta. Finalizado el periodo de caducidad, el contenido de la carpeta será archivado en el pasado y la carpeta quedará vacía para nuevos usos. Tus archivos siguen ahí, en el pasado, listos para ser consultados utilizando HD Lorean.

Sincroniza tus copias

HD Lorean te da la posibilidad de llevarte las copias de lo que has hecho en la oficina a casa, simplemente indica el mismo dispositivo de copias y pide que se sincronicen las carpetas que tú quieras.

¿Quién tiene el control?

Tú y sólo tú. HD Lorean trabaja de manera invisible a tus ojos a menos que tú se lo indiques. Puedes indicar a HD Lorean qué copias de seguridad ha de borrar, qué archivos debe copiar y cada cuánto tiempo, si las copias de seguridad han de estar comprimidas o no… Así que si te gusta tenerlo todo vigilado, HD Lorean no escapará a tu alcance.

¿No te sientes identificado?

Quizá alguna de estas situaciones se parezca más a la tuya. Échales un vistazo, son situaciones reales.


Requisitos

Requisitos funcionales

El usuario puede…

  • Recuperar diferentes versiones (anteriores en el tiempo) de un archivo. Casos de uso que corresponden: CLado, SobUltVr
  • Decidir qué carpetas y archivos tendrán seguimiento de versiones. Casos de uso que corresponden: Config, ConfigExc, AñadirC, EliminarC
  • Decidir en qué soporte físico se almacenarán estas versiones. Casos de uso que corresponden: Config
  • Trasladar las copias de seguridad a otros soportes (tanto copias completas, como historiales de ficheros). Casos de uso que corresponden: Exp,Imp
  • Buscar y mostrar por nombre de fichero o por los contenidos, donde podemos ver todas las versiones de los archivos (incluso archivos borrados). Casos de uso que corresponden: BusBack
  • Gestionar el espacio en disco, de forma que cuando el disco duro se llene, se recomienda al usuario borrar versiones inútiles de archivos o exportar a CD's y DVD's.Casos de uso que corresponden: Exp,Imp
  • Definir fecha de caducidad a los archivos, de forma que se borren de las carpetas (ya están guardados en HD Lorean) los archivos más antiguos o los que menos se han usado últimamente. Casos de uso que corresponden: DimTemp
  • Contratar un servicio de copias de seguridad por red en servidores dedicados. Casos de uso que corresponden: AlmEx
  • Dedicarse a otras tareas con total normalidad y despreocupación, el sistema trabaja de forma autónoma y transparente. Tus archivos están bajo control desde el momento en que los creas. Casos de uso que corresponden: GuaVrAuto
  • Apagar el equipo con HD Lorean funcionando, éste continuará desde el mismo punto cuando el ordenador se vuelva a encender. Casos de uso que corresponden: IntBack
  • Excluir las copias de seguridad de determinados archivos (por tipo, tamaño, etc). Casos de uso que corresponden: ConfigExc
  • Posibilidad de borrar un archivo y todas sus versiones (o algunas) del backup. Casos de uso que corresponden: BorraT, BorraV
  • Ver el estado de las carpetas en cada momento del tiempo. Distintos interfaces de uso. Casos de uso que corresponden: VerVerCarp
  • Restaurar archivos/carpetas en otro equipo y sincronizarlos entre ellos. Casos de uso que corresponden: Sinc
  • Varios ordenadores/usuarios pueden compartir el mismo soporte físico. Casos de uso que corresponden: CompDisp
  • Aplicaciones de terceros pueden utilizar el sistema para sus propias necesidades: Por ejemplo: Los juegos cargan todas tus versiones de partidas guardadas, o el programa de correo puede buscar correos borrados.Casos de uso que corresponden: ApTerceros

Requisitos no funcionales

Requisitos recomendados del sistema:

  • Tener un ordenador con Linux. Recomendado Ubuntu 7.10 con inotify y 10 GB de disco duro libre. Red, otro disco duro bastante grande y grabadora de DVD.
  • Entorno de escritorio Gnome. Recomendado 2.20
  • Python 2.4. Recomendado 2.5
  • Compilable desde fuente. build-essentials
  • Beagle
  • Acceso de lectura a los archivos que se quieren guardar.

Requisitos no funcionales ampliados

  • Backups incrementales.
  • Inotify (se archiva cada versión de un fichero, siempre que se guarde) hay que mirar para no guardar temporales, swap de programas, etc… Con Inotify no hay problema, se puede seleccionar lo que guardas a nivel de fichero o de directorio, así que podemos hilar tan fino como queramos en ese sentido.
  • Funcionamiento en modo desconectado del almacenamiento externo.
  • Monitorización del espacio del HD.
  • Uso logarítmico del disco duro/tiempo: Cuanto más antiguas sean las copias más separadas en el tiempo estarán las versiones. De los cambios recientes, por ejemplo última semana, el archivo están todas las versiones. Probablemente esto exija colapsar copias de seguridad, de forma que se mantenga la integridad en las copias incrementales.
  • Optimización del uso de CPU y disco.

Ventajas de la aplicación

  • Guardado de la información de modo logarítmico, de modo que cambiar algo en un archivo de gran tamaño no ocupe de nuevo el tamaño completo, sino que ocupa el espacio de los cambios realizados (Inbox de correo, bases de datos, etc.)
  • Integración con Nautilus de GNU/Linux. Se muestran lineas de tiempo.
  • API para aplicaciones externas.
  • Transparencia y código libre.

Viabilidad

  • La base de la aplicación es perfectamente viable a base de guardar copias de los archivos en carpetas ocultas cada vez que se detecten cambios. Es necesario también un índice de datos para búsquedas eficientes, implementable mediante una base de datos como p.e. sqlite.
  • Métodos más eficaces de almacenamiento dependerían de la plataforma (p.e. un sistema de archivos que almacene solamente cambios como ZFS, o diffs binarios entre archivos).
  • Sin Tracker instalado en los equipos cliente se complicará bastante la implementación de clasificación de archivos y su búsqueda. Es factible, no obstante, ampliar el source de Tracker para adaptarlo a nuestras necesidades.
  • La comparación de versiones es trivial para archivos de texto, y para archivos binarios con formato conocido se pueden reutilizar los extractores del citado Tracker. Queda simplemente conseguir una interfaz de usuario sencilla y eficaz.
  • El mecanismo inotify del kernel de linux, presente en los equipos cliente, permite indexar un archivo en el momento que es creado y evitar largas búsquedas de cambios.
  • La pausa y reanudación de los backups requerirá de un sistema de transacciones similar al de una base de datos o un sistema de ficheros con journal; es necesaria investigación para detectar si es posible reutilizar funcionalidad presente en el sistema.
  • Sincronizar archivos entre dos sistemas, ya sean interno y disco duro externo o dos ordenadores con red requiere todavía investigación pero podría hacer uso de rsync, o de mecanismos similares al control de versiones distribuido en caso de que se vayan a integrar las historias de cada archivo.
  • Servidor externo de almacenamiento es viable si se nos proporcionase la infraestructura necesaria, pero hasta el final del desarrollo del proyecto será dificil integrarlo.
  • GTK es una tecnología nueva para el equipo, así como python, lo que dificultará el desarrollo. Confiamos en que sea lo bastante sencillo de usar como para que sea mínimo el aprendizaje, a la vista de su gran implantación en el software libre. Se usará para ello pygtk.
  • El equipo tampoco conoce el uso de dbus para comunicación IPC entre backend y frontend, y en general entre los diferentes procesos que pueda tener la aplicación.
  • La integración y transparencia vendría por un lado del software como demonio, y por otra parte de integrarlo con el entorno de escritorio (concretamente con nautilus); es necesaria investigación también al respecto para determinar las posibilidades, pero en última instancia podría ser modificado el código fuente.

Alcance

  • Una primera fase de la aplicación sería desarrollar el backend con la funcionalidad mínima para soportar la base de la aplicación, y un desarrollo de interfaz para probarlo.
  • Es importante también desarrollar lo antes posible la integración con el entorno de escritorio a fin de estudiar la usabilidad del sistema, fundamental en los requisitos del mismo.
  • El almacenamiento diferencial de copias para utilizar poco espacio en disco es viable (mediante diff o mecanismos similares).
  • Externalizar copias de seguridad requerirá de investigación sobre la arquitectura pero es factible.
  • La caducidad automática de las copias de seguridad es viable, pero en una primera fase del desarrollo se hará manualmente para asegurarse del funcionamiento.
  • La sincronización en red será complicada pero en principio no es diferente a sincronizar con un disco duro externo.
  • La integración con el entorno de escritorio dependerá de las facilidades que proporcione el mismo (como plugins para nuevas vistas del navegador de archivos).
  • Realizar un API sencillo será una prioridad media en el desarrollo; integrar alguna aplicación existente con el mismo es menos viable al exigir el conocimiento de esa aplicación a nivel código fuente para modificarla.
  • El servidor externo no es viable en el tiempo proporcionado, puesto que además del sistema completo y estable finalizado requiere de infraestructura que no tenemos y de administración que está completamente fuera del ámbito del desarrollo.

casos-de-uso

Included page "doc:casos-de-uso-merged" does not exist (create it now)


Historias de Uso merged

Included page "doc:historias-de-uso-merged" does not exist (create it now)


Riesgos

Tabla de identificación

Nombre Tipo Descripción
Wiki se cae Proyecto El wiki se cae y no podemos acceder a lo guardado en él o utilizarlo para seguir documentando
No llegar a dominar beagle Tecnológicos Nadie domina beagle en el grupo de trabajo
Nos llevamos mal Negocio Discusiones dentro del equipo, faltas a las reuniones…
Falta organización Negocio Falta de coordinación entre los miembros del equipo
El programa no funciona en los laboratorios Proyecto Los ordenadores del laboratorio no tienen las tecnologías o permisos necesarios
No llegar a dominar inotify Tecnológicos Nadie domina inotify en el grupo de trabajo
No llegar a dominar glade Tecnológicos Nadie domina glade en el grupo de trabajo
No hay conexión a internet Proyecto Se cae el servicio y nos quedamos sin forma de trabajar durante un periodo de tiempo
El repositorio se cae Proyecto El servidor donde alojemos el código se cae
Falta de tiempo Proyecto El tiempo para realizar el proyecto se nos queda corto
Se corrompe un backup Producto Un backup del programa se corrompe
Ocupa demasiado espacio Producto El programa o sus backups ocupan demasiado espacio en disco.
Demasiado lento Producto El programa ralentiza en exceso la CPU o memoria, o es demasiado lento haciendo backups
Programa difícil de usar Producto El programa es demasiado complicado de utilizar para el usuario medio, o poco intuitivo, o no es predecible y las opciones no hacen lo que se esperaría.
Programa con funcionalidad insuficiente Producto El programa se queda corto en cuanto a funcionalidad.
El programa no es fiable Producto El programa tiene problemas al ejecutar y es inestable, posiblemente corrompe backups.
Nadie contrata almacenamiento Negocio Nadie contrata la opción de guardar los backups en el almacenamiento extra
Costes almacenamiento Negocio No sale rentable mantener el servicio de almacenamiento extra
Se cae el servidor de almacenamiento Negocio El servidor de almacenamiento extra se cae y provoca el enfado de los usuarios
El equipo no rinde Proyecto La gente pasa del proyecto y se retrasa por falta de trabajo
Parones temporales Proyecto Parones en el trabajo debido a puentes o exámenes
Falta de material Proyecto El material a entregar falta por falta de tiempo
No nos aclaramos con launchpad Tecnológico El launchpad nos da problemas y no nos aclaramos con el
Incompatibilidad de horarios Negocio Los horarios nos impiden reunirnos todo lo que nos gustaría
No dominar GTK Tecnológico Nadie domina GTK en el grupo de trabajo
No dominar nautilus Tecnológico No conseguir integrar el programa en nautilus
No dominar dbus Tecnológico No conseguir manejar el uso de dbus (sistema de comunicación interproceso)
El profesor suspende una entrega Proyecto No gusta el desarrollo seguido
Problemas de personal Proyecto Enfermedades, deserciones de la asignatura, etc.

Comentarios tabla identificación

Tabla de análisis:

Nombre Probabilidad Consecuencias Prioridad de solución
Wiki se cae Impredecible (Baja) serias / muy serias (según el tipo de caída, temporal o permanente, y si se pierden datos) Muy alta, lo primero que vamos a solucionar.
No llegar a dominar Beagle Baja tolerables (la integración con beagle no es crítica para el éxito del núcleo del proyecto, es funcionalidad adicional) Media
Nos llevamos mal Media muy serias Baja
Falta organización Alta muy serias Alta, estamos en ello
El programa no funciona en los laboratorios Baja catastróficas Muy muy alta (surgirá en cuanto empecemos a desarrollar código)
No llegar a dominar inotify Muy baja muy serias (componente crítico para que el conocimiento de qué es necesario archivar sea eficiente) Alta
No llegar a dominar glade Muy baja serias (glade es el editor de interfaces) Baja
No hay conexión a internet Media-baja tolerables Baja (ajena a nuestro control)
El repositorio se cae Baja insignificante insignificante
Falta de tiempo Media tolerables a catastróficas (en función de en qué punto del desarrollo del proyecto nos quedásemos) Baja
Se corrompe un backup Baja catastróficas Esperemos tener el proyecto avanzado cuando pase
Ocupa demasiado espacio Media (a priori no lo sabemos pero tenemos el limite impuesto por el laboratorio) catastroficas Baja
Demasiado lento Alta (muchas escrituras) serias (el programa no sería demasiado usable) Media
Programa difícil de usar Baja serias Media/Alta (si es demasiado complicado de utilizar el usuario no lo usará; si es impredecible el usuario achacará -con razón- el uso incorrecto a los desarrolladores)
Programa con funcionalidad insuficiente Media tolerables a serias (según cuánta funcionalidad falte, y cómo de crítica resulte) Alta
El programa no es fiable Baja catastróficas Muy alta
Nadie contrata almacenamiento Muy alta serias Baja (actualmente nuestra prioridad es la aplicación, y no el modelo de negocio que pudiera desarrollarse alrededor)
Costes almacenamiento altos Alta serias Baja (a priori, consideramos el trabajo sobre las características del modelo de negocio secundario. Además es un problema que, si está resuelto a nivel usuario individual, facilitaría su resolución a nivel almacenamiento compartido)
Se cae el servidor de almacenamiento Media muy serias a catastróficas (según consecuencias de la caída) Baja
El equipo no rinde Media muy serias Muy alta
Parones temporales Alta (pero predecible) serias Alta
Falta de material Muy baja / infinito serias Baja
No nos aclaramos con launchpad Media-alta tolerable Media-alta
Incompatibilidad de horarios Muy alta tolerables (según el grado de incompatibilidad) Alta
No dominar GTK Baja Muy serias (una interfaz usable es crítica para el éxito del proyecto) Alta
No dominar Nautilus Baja tolerables Baja
No dominar dbus Baja serias (dificultaría la separación backend-frontend) Media
El profesor no aprueba una entrega Media serias Alta
Problemas de personal Baja muy serias Alta (Siendo pocos una deserción es más crítica, ya que necesariamente estamos más especializados, lo que aumenta el riesgo)

Comentarios tabla análisis

Included page "riesgos:tabla-planificacion" does not exist (create it now)

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License