EVO shared storage by SNS enables a collaborative edit workflow for all major NLEs, as well as asset management and file automation tools to organize and ensure safety of data. Backblaze has been validated for use with EVO. To use this product with Backblaze, please follow the instructions below.
Reference Architecture
Prerequisites
- EVO version 6.1.5
- Slingshot version 1.4
- An active Backblaze account
1. Log in to the Backblaze account and navigate to My Account > App Keys to generate an Application Key for the bucket EVO should access (or refer to your existing key information, which is only displayed at time of creation). The Application Key needs Read and Write access for the intended bucket.
2. Copy your new application key, which will only appear once.
3. Navigate to the B2 Cloud Storage > Buckets menu item, and note the Endpoint URL address for your bucket:
Follow the steps outlined below to connect EVO to your Backblaze bucket.
1. On the EVO web interface and navigate to the Slingshot > Settings > Aliases card.
For EVO Version 6.x: On the EVO web interface, navigate to the Slingshot > Aliases page.
2. Click the + symbol. For EVO Version 6.x: Click Add Alias.
3. Give your Alias a name and select Amazon S3 as the schema.
4. Under Region, select Custom host and provide the correct service URL (Endpoint) for your Backblaze region, and enter the bucket name as it appears in the Backblaze Console.
Enter the AccessKey (keyID) and SecretKey (applicationKey) generated in the Backblaze Console.
5. Save the changes, allow a few moments for authentication to complete, and confirm a Volume ID is displayed to show registration was successful.
6. Navigate back to the Slingshot page to create a new replication job.
7. Choose the source for what should be replicated to Backblaze, and set the destination as the S3 target. Note that by default this will create a folder on the destination with the same name as your job. The relative path can be changed if needed, or left empty to create the files at the root of the bucket.
Note: If ShareBrowser is used with EVO, care should be taken not to manually modify the destination content after replication, since this can create a discrepancy in the ShareBrowser database. It's expected that only Slingshot will be used to modify replicated contents at the destination directory.
Note: Lifecycle rules may move the data into object storage, in which case Slingshot will lose visibility for it.
The method used by default is Copy/Replace, which means content removed from the source will not be removed at the destination, so the job will only ever add updated content. The other option is Sync/Remove, in which case content deleted from the source will also be deleted from the destination the next time the job is run.
More details about advanced configuration options are found in this Slingshot Knowledge Base article and SNS support can provide additional assistance if needed.
Have more questions? Submit a request