title: SQL Server disaster recovery using replication?
body: <p>I have a project coming up that needs offline capabilities and the least amount of downtime possible.</p>
  
  <p>There should be a central server on site with IIS and SQL Server to host my ASP application but in any kind of faillure the data in this database (100MB at most) should not get lost (10 minutes of data lost is a big problem) and it should be possible to restore within 30 minutes.</p>
  
  <p>The best I can come up with is to set-up database replication to Azure with an identical spare server stored in a nearby facility.</p>
  
  <p>I haven't used replication before so I was hoping to get some answers here...</p>
  
  <ol>
  <li>I Always prefer a simple set-up because it's usually more stable. Can I consider SQL replication as 'stable'? I known it's a tested technology but what kind of problems may I run into?</li>
  <li>The spare server could be down for months (yes, ideally it should be booted once a month). How long could it take before replication kicks in and how long till it's finished?</li>
  <li>Is it even possible to replicate an SQL server after it has been down for so long?</li>
  <li>Ideally, when there is a problem with the server some 'dummy' user should unplug the main server and boot the spare server without any intervention by IT. Are there any required tasks to 'force' replication?</li>
  <li>Currently there is no wired internet connection. Only an excellent 4G (yes,.. unstable by definition). Is a wired connection required for flawless replication or shouldn't 4G be a problem?</li>
  </ol>