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.