While I agree with Bart that you shouldn't use the Deployer with multiple destinations as a pure high availability option and use a SAN solution where possible, I do see a lot of use cases where only Binaries should be deployed. Think for instance of a subdomain to host images from in case there are a huge amount of images or other binary assets which you want served separately from your pages, or other CDN like approaches.
So, while you can't exclude items to be published when Tridion items are deployed, it is perfectly feasible to publish to one single Deployer Destination and to let a Storage Extension handle Binaries in any way you want. In fact it's only a couple of lines of code if you override the standard Binary DAO:
public class MyBinaryContentDAO extends FSBinaryContentDAO
public MyBinaryContentDAO(String storageId,
String storageName, File storageLocation, FSEntityManager entityManager)
super(storageId, storageName, storageLocation, entityManager);
public MyBinaryContentDAO(String storageId, String storageName, File storageLocation)
super(storageId, storageName, storageLocation);
public void create(BinaryContent binaryContent,
String relativePath) throws StorageException
// Calling the super method will keep the binary managed.
// Handy when unpublishing
* At this point you can do anything you like with the binary,
* - posting it to a webservice
* - copy it to an array of different server shares or paths
* - change the actual content of the binary before saving it
* You can even call the FileUtils static methods (pseudo code):
InputStream inputStream = new ByteArrayInputStream(binaryContent.getContent());
catch (IOException e)
// TODO Auto-generated catch block
public void update(BinaryContent binaryContent,
String originalRelativePath, String newRelativePath) throws StorageException
super.update(binaryContent, originalRelativePath, newRelativePath);
// see the create method.
public void remove(int publicationId,
int binaryId, String variantId, String relativePath) throws StorageException
// Remove your binary from all the places where you've put it.
// Should you need the actual content, you can do:
// BinaryContent contentToRemove =
// this.findByPrimaryKey(publicationId, binaryId, variantId);
// Do your removal stuff here, pseudo code
This way, you don't have to fiddle around that much with exotic storage configurations and you don't get to have multiple destinations and deployer setups to maintain.
So while the new Storage configuration is a bit more restrictive than the old Broker configuration, the flexibility you get by having the DAO mechanism imho outweighs that (if you're not afraid of Java).