Salesforce provides a “Weekly Export Service” for customers with Enterprise, Performance, and Unlimited Editions. I expect that many of us aiming to use this service as a Salesforce automated backup solution find our way to this “Exporting Backup Data” page in the Salesforce Success Community. Very clearly on that page, one can read the following about how long those backup files will remain in place once they arrive upon backup completion: “Zip files are deleted 48 hours after the email is sent. The 48-hour time limit doesn’t include weekends, which means if your download file is ready on Thursday at 4 p.m., that file isn’t deleted until Monday at 4 p.m.”
However, that’s not always the case. I recently started a new job with a company that’s been using Salesforce for 7 years, and the org has A LOT of data; so much, in fact, that it took 12 days for the first full “weekly export” to arrive. At least, I THINK it took that long; let me explain why I’m uncertain. What I learned yesterday is that the initiation of the NEXT export job results in deletion of the backup files from the PREVIOUS export job. So, I got an announcement at about 10:00 AM on Saturday, 12/20/14, that my export was complete. On Monday morning, the FIRST business day after the announcement of the export’s completion, I started downloading files at about 8:30 AM EST. At about 10:00 AM EST, the backup files, all 241 of them, disappeared. I’d downloaded about 4.
When I called in to Salesforce Premier Support to rave that I should have almost two full business days left to download these files, the rep explained that it wasn’t the 48 hours over business days schedule that resulted in the deletion of the backup files. It was, indeed, the next export job commencing that caused the deletion.
The solution I was pitched was to delete the weekly scheduled job, and allow the currently executed job to complete. Then, when that job finishes and my team has downloaded all the files, we can manually kick off our next export. That should prevent this problem moving forward, but it adds another point of opportunity for human error in maintaining the backup process, about which I’m not thrilled.
The truth is, this discovery is just one more factor that is increasing the urgency of figuring out an automated backup solution for our Salesforce org. We need a frequent backup to protect us against data losses / corruptions caused by human error. Yes, Salesforce backs up data for “disaster recovery purposes,” but make sure you read up on what that means. According to Salesforce, it costs a minimum of $10,000 (US) and “and usually takes a minimum of 15 business days (3 calendar weeks).” I don’t know about your company, but 15 days waiting for a data restoration in any emergency that would justify a $10,000 fee would be WAY too long to wait for us.
I’m curious about what other users with large amounts of Salesforce data have done to automate a frequent backup process. I’m looking at scripting with Salesforce DataLoader, I’ve started experimenting with the Jitterbit Data Loader, and I’m open to just about anything. If you have any thoughts on the subject, I’d love to get a comment from you here. Thanks in advance!
Josh Gilliam's Blog: Exploring the "PaaSible!" 
We use a tool called CopyStorm to near real time back up our SF org to MSSQL. it work with a lot of other DB. This gives us the backup and restore but it also saves us user lic for reporting as well.