2

Dealing with the lack of, or at least in my opinion, of turn-key, 100% complete backup & recovery on Salesforce has killed my normally approach to rolling out new systems; that being, move as fast as possible, but be able to recover x-days back if needed.

One of the issues is that the organization is using the Non-Profit Starter Pack, which is a set of managed packages that the Salesforce Foundation offers in a default build. Issue is that the default build once deployed is not easy to recover to my knowledge, and while it is easy enough to backup data - I do not want to be in the position of paying Salesforce $10k to do any sort of recovery, be it data, installing packages, etc; that said, even after finding documentation on manually installing the Non-Profit Starter Pack from scratch, this seems like it might be a huge pain to do.

At this point, the only option I am able to think of is to roll-out the default build, do a backup using a third-party service such as (Backupify, Spanning, CloudAlly, OwnBackup) - and make sure that the core backup & recovery plan to start does not require at any point the migration of IDs; meaning no org-to-org migrations.

Is there something I am missing, or should I invest more time into being able to do a full-backup and recovery myself?

Might be worth noting that in my opinion, doing the weekly export of data is fine - though the issue is that does not cover the Non-Profit Starter Pack or Saleforce configs, and currently, unless I am able to confirm that that backup is recoverable, I don't see the point in downloading data, api-metadata, etc; hence why going with a third-party solution makes the most since to me, since I am able to confirm I am able to recover a system without much effort.

Improve this question
1
  • 1
    The weekly backup absolutely should include the NPSP configs, as those values are stored in custom objects or non-protected custom settings. Check that again.
    – DavidSchach
    Apr 26, 2014 at 3:01

1 Answer 1

Reset to default
2

While not a direct answer on a complete backup, I think following some best practices for deploying changes to Salesforce might help mitigate some of your concerns. If you're a Foundation customer, then your instance is able to create Sandbox orgs where you can test out changes before deploying to production.

When you have an instance with multiple applications installed, rolling back your data to a few days ago gets really tricky. Do you just want to remove the new fields you added and their data? Do you want to roll all your records back to 3 days ago as well? What if a user updated a phone number manually and you want to keep that change?

The better solution is to test the changes in metadata first in a Sandbox then deploy those changes to production. Salesforce provides a number of ways to handle moving changes from Sandbox to Production ranging from manual change sets built and deployed through the web UI to full scale Continuous Integration automation using Jenkins and Git to track changes. If you're interested in the later route, I've documented the process we use for developing the next version of the NPSP here http://salesforcefoundation.github.io/CumulusCI/ Our process is more complex because we're building a managed package, but I'd be happy to help answer questions if you wanted to look into full scale automation of your internal development process.

Specifically regarding the NPSP packages, @david-schach should be correct. We're also about to roll out a major upgrade to the NPSP which will make installation and configuration a lot easier in addition to adding some great new features.

Improve this answer
1
  • +1 Wow, awesome; just a quick followup to say thanks for posting, and yes, Jenkins + Git is likely the option I'd select. About to headout for the day, but will look into your answer in detail later, and reply with a more relevant response. Again, thanks.
    – blunders
    Apr 28, 2014 at 13:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .