7. Remarks

The source as well as the target directory may lie on any file system, i.e. mounted ones using nfs or cifs. Be aware that the restrictions of the respective filesystems apply. For example, it may still be unstable to create files larger than 2 GB on samba/cifs mounted partitions, or on FAT partitions. Also, changing owner and group or their permissions does not work on these filesystems.

When studying the crontab you will notice that some (or most) of the ISiBackup jobs are run as root. This is "easy", as it makes sure ISiBackup can read all it needs. It may have some security consequences I am not fully aware of, and I have already thought of running it as nobody:wheel. At least, the backup directories themselves are owned by admin:backup (on my systems at least, bound to change to conform to debian policies). I could eevn imagine having the data backups run as nobody:staff, but that might fail as I have excluded some accounts from staff on some systems, and as backing up configuration parameters as part of the data surely fails then. There's work to do here.

I found it quite probelmatic to pass local values back out of a subfunction in bash. Any way I tried, the values just got lost. So in the end, I implemented a method of writing local values out to temporaray files, from where I would read them back from within the "outer" routine. This is not "nice", but it works. Anyone with a better solution is welcome.

The progress indicator was meant to be overwritten with each change. Instead it fails to overwrite part of the line, which produces some untidy output. Here as well, I conducted some tests, but better solutions are welcome.

Beware not to do "in-place" backups, i.e. having Source and Target directory in the same place. While this might work, ISiBackup was not intended to handle it correctly, and in the case of "separate" operation mode it is doomed to fail, probably resulting in data loss. If space is tight, you better enable the automatic deletion of the original after each directory backup (using the ... the parameter ... what was it again ... eh ... to be written).

Symbolic links are not being followed, but stored as link. So if, for example, you include /*/, and /var is a link to /usr/var, then /usr/var will be backuped, /var will be backuped as a symbolic link, and all exclusions to /var subdirectores are ignored as there are none - you would have to reformulate them as exclusions to /usr/var subdirectories. But if, on tthe other hand, you include /var, it does not matter if it is a symbolic link, as it is at the root of the find command, and therefore the find will work on it.

ISiBackup has mainly been tested on systems where there is a partition for each of /, /usr, and /var. /home is a link to /var/home and /var/home is a link to /var/local/share/home (don't flame me, it makes sense here). On some systems, there was no partition for /var, but /var was a link to /usr/var. That meant changing all directory exclusions. Of course it does not work to exclude /usr/var as we might have /var, because /var is stored as symbolic link. It's necessary to change all exclusions from /var/... to /usr/var/... on that system.

Usually I use isibackup in poll mode, and go for full encryption with cpio data format for host backups and zip format for the data backup. Using it in poll mode nmeans the backup is generated locally, and it will be fetched later using a remote login mechanism from the backup server to this machine. This way I have an easy option when a disk gets full. The first thing that can be deleted is the locally generated backup (don't frown), as you can just switch over to pull mode, where you generate the backup remotely.

In the default setup, isibackup --data also saves most of the configuration files. This is provided as a feature in case you "forgot" to backup the host lately. Be aware that this may help you resetup your system after a crash, but that it is not sufficient.

Also be aware that by default isibackup skips all files on other filesystems, if they have not been included in the *include_dir* configuration files! this is to prevent backing up other hosts automatically, but it may also prevent backing up files on other harddisks on this system!

Whenever you have a question regarding an option or a problem that has not been described here, please look at the source code. The main ISiBackup script is called isibackup and is a shell script. That means that what you run is actually the source, and you may have a look into it by just issuing less $(which isibackup)

After having used ISiBackup for some time, you might have got used to the relatively fast "in-place refresh" of backups compared to the recreation of backups. Just remember that an in-place refresh never deletes any directory. That is, if you deleted a directory in the drive you back up, that directory will remain to exist inside your backup. In the unfortunate case where you have to restore a backup, that directory will be restored to. Even if you might be happy to get back those contents, the backup is not a true backup of the original, but something more.