I discovered the pax command recently, and was amazed at how efficient it is when copying locally from one SSD to another, for instance.

For local backup, I'm contemplating replacing a rsync solution with pax, however pax seems to be missing the --link-dest option that is so convenient for incremental backups (creating hard links to the previously backuped version for identical files).


  • is there a workaround to have pax + ? give a behavior similar to rsync --link-dest... (maybe better than 1. make hard links for identical files 2. run pax -k)

  • any other efficient command / solution to reach a similar result efficiently?


The pax program is not useful for incremental backups.

The new POSIX.1-2001 extended headers for the tar format (called "pax"-format) that have been taken from the Solaris TAR enhancements from 1997 however are a really good base for incremental backups since this concept allows to be enhanced to archive all possible meta data.

It seems that you like to do cumulative incremental backups/restores locally in order to mirror a filesystem locally. star is perfectly suited for your wish, see http://schilytools.sourceforge.net/man/man1/star.1.html

The instructions on how to do cumulative incrementals is currently on page 53 under the section SYNCHRONIZING FILESYSTEMS

Note that if you are on an operating system with a slow filesystem cache (like Linux) or using a transactional filesystem like ZFS, it is recommended to use the option -no-fsync or extraction will be extremely slow since star by default extracts files in the secure mode that allows to detect file system write errors while flushing cached data. Also use the option -pax-o binary on the left (create) side to avoid path name conversion problems in case that there are files in the filesystem that different locales than your current shell.

The method that star uses is the same as with ufsdump/ufsrestore:

Star manages a file /etc/tardumps with time stamps levels and filesystem names for the create side of the incremental backups.

For the extract side of the incremental restores, star manages a file star-symtable in the root directory of the extract filesystem. This database contains a list of old inode numbers and the related new inode numbers in order to be able to detect renamed and removed files.

Star has been massively tested with incremental dumps and restores during more than 10 years and never caused any problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.