Amazon S3 & Syncrify
Amazon S3 is a cloud service used to store files. While it is possible to use Syncrify server in
conjunction with Amazon S3, there are some important notes to consider.
Amazon S3 / Syncrify Issues & Concerns
- Is Amazon S3 charging users per read/write sequence?
- How much network traffic is introduced when using Syncrify in conjunction to Amazon S3?
- How do I integrate those mapped Amazon S3 drives with Syncrify server's user repositories?
Amazon S3 / Syncrify Conclusion
These are all valid questions with cost/performance implications. So, lets take a look at
what I found for all three issues:
- We're not sure how Amazon charges for S3 but we do know that the processes in Syncrify
that copy files will possibly read and write many times during a backup.
If you have simple copy enabled the amount of read/write requests maybe less, however.
- When there are mapped drives of any type used in conjunction with Syncrify,
the network traffic doubles as the first 'hop' of information goes from the client to
the server, then the server to the remote/mapped drive. This is inefficient and can cause
unnecessary bandwidth charges if they apply
- While using mapped drives is not recommended, it is certainly possible.
Therefore if you absolutely must use Syncrify with Amazon S3 please check out the
Synametrics knowledge base article about how to incorporate a mapped drive.
The biggest challenge when it comes to mapped drives is the scheduled task/file permissions problem.
Mapped drives only exist when a user is logged in on the OS, so if you're running the Syncrify
scheduled task as the local system account that mapped drive won't exist from the operating system perspective.
This detail is easy to overlook and can cause a bit of confusion if not addressed.
Mapped drives as Syncrify user repositories
The knowledge base article for mapped drives is available
||6/21/13 4:51 PM
|Last updated on:
||6/26/13 2:45 PM