machielr: your copy process may be blocked by large on-going transactions, that have to finish before the non-innodb bits are copied (mysql tables and .frms). There are some things that you can try, depending on the situation. First one, would be to avoid long open transactions while the last part of the backup happens (the non-transactional copy). Second, using --rsync (that will not avoid the locking but you may have copied most of the non-transactional bits before the locking, so if you cancel the copy, you may still save something, although in a non consistent way). You can use --no-lock, that will avoid the process to be blocked, but if you execute an ALTER TABLE or update a non-InnoDB table during the copy process, the backup may not be consistent.
The real solution will probably come by using the new features in the latest releases of xtrabackup: http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/improved_ftwrl.html
with --lock-wait-timeout or --kill-long-query-type you can control the specific behaviour of the backup process: making it fail immediately and retry later or kill the offending queries to allow the backup to continue. Obviously, use both options with caution.