Mitose Code
Status: Beta
Brought to you by:
magicmuscleman
Menu
▾
▴
Tree [21d67b] master / History
Read Me
Mitose installation instruction
-------------------------------
1. Compilation:
In the following it is assumed that you are in the Mitose directory
(where the file you are reading resides). You can change the paths
accordingly if that should not be the case.
1.1 Prepare libconfig
In order to compile Mitose you need the libconfig library.
1.1.1 Your distribution includes libconfig
If it is part of your distribution, you can simply install it's development
package using your package manager as root.
For example when using Debian Squeeze, type
# apt-get install libconfig8-dev
1.1.2 Your distribution does not include libconfig
If it is not part of your distribution, you can get the most recent version
from http://www.hyperrealm.com/main.php?s=libconfig
After downloading unpack it and compile it.
$ wget http://www.hyperrealm.com/libconfig/libconfig-1.3.2.tar.gz
$ tar -xf libconfig-1.3.2.tar.gz && ln -s libconfig-1.3.2 libconfig
$ cd libconfig && ./configure --prefix=$(pwd) && make && make install && cd ..
1.2 Compile Mitose
This should be as simple as:
$ make
2. Installation
If you want to have a daily backup, you can copy mitose to make it a daily
cron-job. For desktop usage it is recommended to install anacron, too.
You have to be root to do this. If you use a sudo based distribution you have
to substitude "su -c" by "sudo" in the next commands.
It is recommended to let root own the file and remove the write and execution
bits from the file.
$ su -c "cp dist/Release/GNU-Linux-x86/mitose /etc/cron.daily"
$ su -c "chown root:root /etc/cron.daily/mitose"
$ su -c "chmod o-wx /etc/cron.daily/mitose"
3. Configuration
Edit mitose.conf according to your needs and with the help of the comments
therein. Copy it to the /etc directory and restrict the write access to root.
$ su -c "cp mitose.conf /etc"
$ su -c "chown root:root /etc/mitose.conf"
$ su -c "chmod o-wx /etc/mitose.conf"
4. Usage
You do not have to do anything more. From now on Mitose automatically backups
your files on a daily base. The backups are named in the format YYMMDD-HH:MM,
coding the year, the month, the day, the hour and the minute respectively.
During the first backup all files have to be copied, so this will take some
time. You can start it manually by executing
$ su -c "/etc/cron.daily/mitose"
and check the backup manually if you want.
All further backups need only the size of the changed files and a bit
administration overhead. Depending on you configuration this can be e.g.
100 MiB for 20 GiB of data.
If there is not enough space left for a new backup, the oldest ones get deleted
by Mitose until the new backup fits on the partition. The most recent success-
ful backup gets never deleted.
A backup is successful if it could be created without an error. If it is not
successful it has a file named "INCOMPLETE" in its main directory. During the
creation of a backup this file is present, too. A backup can stay unsuccessful
when the computer was shut down when mitose was running. If you have an
unsuccessful backup Mitose will normally create a successful backup in the
next run.
5. Recovery
As full backups are created you can use your favorite way of handling files to
recover files or whole directories. If you want to ensure, that the metadata
of your files (modification time, access time, ownership, permissions) is
recovered, too, you maybe want to use "cp -a".
Mind backups with the file INCOMPLETE in the main directory as these could not
be completed. You can use the files therein, but some files will probably be
missing and the file which was worked on during the shutdown/error will be
incomplete.
The already completed sets are listed in INCOMPLETE, so you can take this list
as an orientation. But mind, that no sync is done by mitose (too time con-
suming). So mitose has successfully commanded the write of the files, but
there is no guarantee, that the files were already written to disk.
6. FAQ
Q: What's up with the name Mitose?
A: Mitose is the German word for mitosis, which was the supposed name, but it
showed up, that there already exists an Apache project with that name
(http://cwiki.apache.org/DIRxSRVx11/mitosis.html) and I wanted to avoid
name clutter and thus stayed with the German word, but Mitose can be pro-
nounced that it sounds like an English word so it should not be a problem.
The idea of Mitose is to work like in biology: do the duplication work in
the background without ever beeing noticed. It works without being con-
figured in nature which should be accomplished as good as possible by the
program. Ok, in nature there is some sort of installation process, but I
won't go into detail here. ;-)
Q: Can the program handle large files (> 4 GB)
A: Yes
Q: Is the program unicode / $"STRANGE_CHARACTER_ENCODING" save?
A: Well, I do not know. If the source and the destination encoding is the same
(those are the most important cases, I think), everything should go well.
If they are different, the filenames in the backup get probably mixed up.
The data in the files will be alright, because they get copied byte by byte,
but if you really need the character encoding transformation, you should
write me a mail, because I do not see this functionality as important ATM.
Q: Does Mitose work with NFS?
A: Yes, but the details depend on the version of NFS.
Version 3 (NFSv3) should work flawlessly (any success stories?).
Version 4 (NFSv4) translates the UID/GID into user/group names, transmitts
those to the backup server, where the names again get translatet to
UIDs/GIDs. Thus all user/group names of the files which are backuped must
exist on the backup server, as well. So possibly additional users/groups
must be created on the backup server.
Another problem with NFSv4 is UID/GID synchronisation. Due to the double
translation of UIDs/GIDs, the same user/group names normally differ between
the client and the backup server. In case of a complete disk failure on the
client, the files cannot be recovered via the original clients OS, and thus
the UIDs/GIDs aren't translated back. So if using a live-system and NFSv4
for recovering it could make sense to first copy /etc/{passwd,group} into
the live system to get a correct back translation of UIDs/GIDs.
Alternatively the find command can be used together with chown and chgrp to
change UIDs/GIDs back manually using the backuped /etc/{passwd,group} and
the backup server's /etc/{passwd,group}.
If all /etc/{passwd,group} are synchronized before, (either manually using
find etc. or LDAP) the recovering should be no problem.
Q: What does the program do with my file cache and what's the matter anyway?
A: The file cache is handled by the Linux kernel and caches the most recent
read data in the fast RAM so it does not have to be loaded by disk again
if it is neaded again in the foreseeable future and thus speeds up your
work enormously, as normally one uses some fixed programms and they get
fully cached relatively fast.
Unfortunately, when a program works in the background the kernel thinks,
that those data is needed from now on and discards the cache with your
useful data when there is not enough RAM for both caches.
In order to avoid this situation, Mitose removes the data from the cache
after using it. Unfortunately this means, that the data of your useful
file cache gets discarded, too, if it gets touched by Mitose, which is re-
garded a bug and will hopefully be fixed, soon.
File system meta data is cached and does not get discarded by Mitose. The
reasons is that those data should not need much RAM under normal usage
(every file needs some bytes, so unless you have a huge number of files ...)
and it does speed up repeated backups a lot, if that cache survives from one
run of Mitose to the other. The last reason (but I have to admit that this
argument has just some weight) is that I would not know how to discard that
information anyway.
Q: What does Mitose do with the different types of files?
A: - regular files get copied (or hardlinked if already in the backup)
- hardlinks cannot be distinguished from regular files (because that's what
they are) so they are treated the same
- symbolic links get copied _unresolved_, so they work when restored only if
the links' targets get backuped, too
- device files and FIFOs are copied
- sockets are _not_ copied
7. Contact
Project home: https://sourceforge.net/projects/mitose/
Author: Patrick Häcker (pat_h@web.de)
