For the transport of data between SFDC and storage location, the Salesforce Partner API uses SSL and is approved by Salesforce.com. We are a certified product, and have been since 2005. There are many DBMS’s that offer SSL SQL connections.

For data at rest, if you chose the on-premise deployment, the database security is up to you. In our Cloud offering, the back end database is the encrypted Enterprise version of SQL Server on a server with no public access in an IBM data center. You do not have any access to even your own data in our Cloud offering.

As far as the auditability of security, if you use the on-premise deployment, you own the security. You can lock down your server so you have to log in to the server to access even the web user interface. If you use our Cloud deployment option, you have no access to anything. Recovery is done via a webinar in consultative mode where our professional services team does the actual recovery.

Archive is defined as the ability to backup and maintain data in a non-SFDC storage location and automated deletion of data from SFDC on a specific retention schedule.  The backup archive of the data would always be maintained outside SFDC based on a separate retention schedule.

RJ handles both use cases. You can set flags in the database and use the product to archive massive amounts of data safely, knowing that you can always recover it. The versioning is on a record level, with a primary backup table for the current image and a secondary table for the prior versions of each record. This gives you lower space utilization, frequent incremental backup of just the changed data, and the ability to see all prior versions of a record. Great audit trail too.

Yes. The only thing you’ll have to do is provide the URL of the Sandbox instance in the configuration. Product pricing is based on Production Salesforce orgs, so this is not even a factor.

No, not the way you’re thinking. Metadata can only be corrupted by a System Administrator, not end users, so there are very few cases in which this would have any value. However, if you were to delete a field or an object, you absolutely could get it back entirely, although you’d have to create the object and fields in the configuration screens before you copied the data back to Salesforce. We never delete data, even if you drop the field from Salesforce.

Relational Junction for Salesforce backs up and will restore typically any Salesforce object that is allowed by the Salesforce API and security rules. You cannot create certain objects in Salesforce, such as AccountHistory, because it’s just not allowed by the Salesforce application. There are no issues with handling binary data, such as Attachments an Documents and ContentVersion.

It would be easier to tell you what Relational Junction for Salesforce doesn’t copy. This is a list of current objects that cannot be backed up because they are not “real” objects or have specific technical limitations of the API in copying records without some sort of specific qualifier.

ActivityHistory
AggregateResult
AssetTokenEvent
AttachedContentDocument
CollaborationGroupRecord
CombinedAttachment
ContentDocumentLink
ContentFolderItem
ContentFolderMember
DashBoardComponent
DataStatistics
DatacloudAddress
DatacloudCompany
DatacloudContact
DatacloudDandBCompany
EmailStatus
EntityParticle
FeedLike
FeedTrackedChange
FieldDefinition
FlexQueueItem
FolderedContentDocument
IdeaComment
ListViewChartInstance
LookedUpFromActivity
Name
NoteAndAttachment
OpenActivity
OwnedContentDocument
OwnerChangeOptionInfo
PicklistValueInfo
PlatformAction
ProcessInstanceHistory
RelationshipDomain
RelationshipInfo
SearchLayout
UserEntityAccess
UserFieldAccess
UserProfileFeed
UserRecordAccess
Vote

The Cloud deployment option — where Sesame manages the service in our Cloud — offers no data access to you for reporting. This would be a security concern, as well as causing performance degradation in our multi-tenant environments.

The on-premise deployment option gives you a relational database with indexed relationship fields for all table joins. You can use any Business Intelligence or reporting product. You can run this on your on-premise servers, Amazon AWS, or anywhere.

Yes, but you actually have to specify what it is that you want to restore by setting a control field on at least the top level of the relational hierarchy, such as the Account, which will recover that Account and all its Contacts, Opportunities, etc. You can recover any record to any point in time using the secondary backup table that contains all the prior versions of every record. You can be selective about what fields you want to recover. There is no option to push a single button and recover everything because that is an implausible use case in practice. Salesforce.com is not a Master File that you would restore to yesterday, it is a living database of changing data from many people that would be very unhappy if you restored the entire dataset back to a point in time.

Yes, Windows Scheduler or UNIX cron or any other job scheduler is normally used to initiate replication or integration jobs. The web client is used to set up and test the job, but is not for normal production job scheduling. The command line interface is very easy to run from any scheduling system.