It seems like backintime uses hard links at the target, not between the source and the snapshots. This means that it would be easy to move the taget directory to a server using for example GIO/gvfs. GIO uses urls for bookmarks, and I believe that the url for a ssh target could be used with a rsync-command with little work. If its ssh-mounts only is ok for us.
Harlinks (same inode-number) in snabshots, another inode for the source-file.
aw@biblioteket:~/Backup/backintime$ ls -i 20110224-100001/backup/home/aw/openerp-client_6.0.1-0_all.deb
6424056 20110224-100001/backup/home/aw/openerp-client_6.0.1-0_all.deb
aw@biblioteket:~/Backup/backintime$ ls -i 20110213-000002/backup/home/aw/openerp-client_6.0.1-0_all.deb
6424056 20110213-000002/backup/home/aw/openerp-client_6.0.1-0_all.deb
aw@biblioteket:~/Backup/backintime$ ls -i /home/aw/openerp-client_6.0.1-0_all.deb
5374595 /home/aw/openerp-client_6.0.1-0_all.deb
aw@biblioteket:~/Backup/backintime$
It seems like backintime uses hard links at the target, not between the source and the snapshots. This means that it would be easy to move the taget directory to a server using for example GIO/gvfs. GIO uses urls for bookmarks, and I believe that the url for a ssh target could be used with a rsync-command with little work. If its ssh-mounts only is ok for us.
Harlinks (same inode-number) in snabshots, another inode for the source-file.
aw@biblioteket: ~/Backup/ backintime$ ls -i 20110224- 100001/ backup/ home/aw/ openerp- client_ 6.0.1-0_ all.deb 100001/ backup/ home/aw/ openerp- client_ 6.0.1-0_ all.deb ~/Backup/ backintime$ ls -i 20110213- 000002/ backup/ home/aw/ openerp- client_ 6.0.1-0_ all.deb 000002/ backup/ home/aw/ openerp- client_ 6.0.1-0_ all.deb ~/Backup/ backintime$ ls -i /home/aw/ openerp- client_ 6.0.1-0_ all.deb openerp- client_ 6.0.1-0_ all.deb ~/Backup/ backintime$
6424056 20110224-
aw@biblioteket:
6424056 20110213-
aw@biblioteket:
5374595 /home/aw/
aw@biblioteket: