Supported Platforms and Tips

The storeBackup tools have been reported to run on GNU/Linux, FreeBSD, Solaris and AIX. They should be able to run on all Unix platforms. Perl was used as the programming language, so you need a working perl implementation for starting one of the programs described above.

StoreBackup is developed and tested on GNU/Linux. For all programs you will get a short help message if you call it with option -h.

StoreBackup stores its data on a local filesystem - or something that looks like a local filesystem. You can store to any filesystem (or virtual filesystem) that supports hard link and the type of data you want to save (e.g., symbolic links or special files like named pipes if you want to save them). The following examples show some of the possibilites. (If you write to remote filesystems, you can speed up things by using option lateLinks.)

is currently (2012) the fastest filesystem for Linux. It is well supported by the kernel and will be available for the foreseeable future.
You can use this filesystem, but there are several reasons not to do so: file system checks may last ``forever'' and it doesn't support hashes for filenames, which means access to the many small files generated from ``blocked files'' is slow.
is the actually most space efficient filesystem for Linux because of tail packing. Space in filesystems is organized in blocks. The block size is typically 4kB, so as an average you will not be able to use around 2kB for each file. If you have a lot of files (esp. when using blocked files with compression and therefore undefined blocked file length) you will lose a high percentage of your space. With tail packing, these not filled last blocks of the files are packed together by the filesystem. Reiserfs is slower than ext4. It is well supported by the kernel and will be available for the foreseeable future.
This fossil filesystem doesn't support hard links or differentiation of files written in uppercase and lowercase letters (try to store a file with filename fileA and one with filea into the same directory). You cannot store your backups with storeBackup on such a filesystem. Naturally, you can save data from such a filesystem using storeBackup.
First of all, you can store your backups on an nfts filesystem. But ownership and permissions will not be available in the backup. Especially if you use ntfs on an external disk or memory stick this might not be an issue. Read the ``important note'' at item ``CIFS'' below in this list!
The Network File System allows you to store your backups transparently over the network (see configuring NFS). Naturally, you can also read your data via NFS if you do not want to run storeBackup natively on the system to save (e.g., for very old Unix system where you do not have a running perl 5).
It is possible to store your data on a CIFS (Samba) share. Beside being a little bit slower than NFS it does not support a multi user mount. So all your data will be stored with ownership of one user only. If your environment is a multi user environment where each user should have direct access to his backup data only, this type of storage is not sufficient for you. If each user is allowed to see all data in the backup or if an administrator does the restore, it's no problem to use e.g., a samba server (which is often the only available storage on small NAS boxes) to store your backups. Naturally, you also read data from a CIFS share, but you have to consider that CIFS only can be mounted on a user basis. It is not a transparent network file system like NFS.
Important note: If you restore your data with you will get correct permissions and ownerships back. doesn't care in any way about the permissions of the files in the backup. The meta information (including hard links in the source) is taken from the meta data files stores. BUT if you use with the option lateLinks and if you can run locally on your Samba file server, you will get all permissions in the backup directory like in the source directory.
A short description how to configure sshfs is placed in FAQ 4. Read the comments about CIFS in the item above for a description of possible restrictions.

Heinz-Josef Claes 2014-04-20