I have been experimenting with running Sitecore on Docker containers for a couple of months now and I am having a lot of fun with it. If you work with many clients at the same time like I do, running Sitecore on Docker brings the big benefit to setup and spin up a client environment in few minutes, simplifying the local environment setup process and eliminating the conflicts that might rise hosting multiple versions of Sitecore instances on a single host machine. If you haven’t tried it yet, I highly recommend to do it.
In this blog post I will describe how to override the default command executed in a Docker container running a sitecore-<topology>-sql image to restore Sitecore databases using SQL database backups generated from a non-Docker SQL server.
Last Friday night one of my clients’ websites went down. Yes, on a Friday night. Why do websites go down usually outside normal business hours? I don’t know why. A Murphy’s Law would definitely explain it saying that “whatever can go down, will go down on a Friday night“.
In case you have to deal with the same issue in the future, I want to share with you my experience and the steps that I followed to recover a corrupted Sitecore web database in the particular circumstances of not having direct access to the SQL server where the corrupted database was managed.
Have you ever experienced a blue screen of death on your computer? Probably yes, nobody is immune. IT systems that host a Sitecore website are not different and they are vulnerable to failures too. The impact of downtime can be devastating for a business, causing loss of revenue and loss of traffic, and damaging a company’s brand image as well.
In my first blog post I am going to describe my approach to setup a Jenkins job to remotely synchronize Sitecore items with Unicorn. Continue reading “My Jenkins Setup with Unicorn”