|The following will:|
|a) Convert the backup to use 128mb bands|
|b) Convert it to use AES-128 for encryption (the default according to https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html)|
|computer-backup should be replaced with the name of the sparsebundle that was created by Time Machine.|
|hdiutil convert computer-backup.sparsebundle -format UDSB -tgtimagekey sparse-band-size=262144 -encryption AES-128 -o temp.sparsebundle|
|cp -a computer-backup.sparsebundle/com.* temp.sparsebundle/|
|rm -rf computer-backup.sparsebundle|
|mv temp.sparsebundle computer-backup.sparsebundle|
|ls -la computer-backup.sparsebundle/bands|
Have you noticed any performance issues with the 128MB encrypted bands? I ran some tests and backups go much faster with the default 8MB encrypted bands (though unencrypted 128MB bands are better). My theory is that if the TM client needs to update 1 byte in an encrypted band it has to move 128MB from the server to the client, decrypt it, update the byte, encrypt it, send 128MB back to the server. When it's unencrypted I suspect that you can simply update at a file offset via AFP so it's much more efficient.
@bits01, I just tried the command to the sparsebundle stored on my NAS (5GHz Wi-Fi connection) and didn't notice any slowdown. However, I am not using AFP, but SMB from Samba 4.8.
I’m not sure whether something has changed from AFP to SMB. Just write here my observation here and hope there is more evidence regarding the slowdown issue.
Daemon tools for Mac contain a working iscsi initiator and I was easily able to backup to such a drive. The problem is how to use it when you need to restore the data? Do you make a physical image and connect it via USB? In my case I was foolish enough to force a 4k sector size over iscsi which seems to make sense and made the backups go faster but when I tried dumping it on a physical drive for restore it didn't work out at all as the partition table used different units as did the filesystem - I think that could have been corrected but since I had another backup I didn't bother to try.