Índice
Introducción a HD Lorean
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. |
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)
Comentarios tabla identificación