- \n
- after upgrading I did not know my old WordPress password, so I had to reset that.<\/li>\n
- upgrading WordPress themes and plugins to the newer versions<\/li>\n
- add missing content to the major pages that needed it<\/li>\n<\/ul>\n<\/li>\n
- Evaluating what is missing from the blog posts, and adding the content a second time.\u00a0 I know my last backup did not contain images, so there is some rework to do there.\u00a0 While I was on vacation, I also changed the theme of my WordPress site.\u00a0 Much of that will need to be redone.\n
- \n
- ask Google to reindex my site as the structure as changed.<\/li>\n<\/ul>\n<\/li>\n
- Restore\/reconfigure GitLab<\/li>\n
- Setup a new backup strategy that keeps me more up to date<\/li>\n
- Write all of this down to aid in future disaster recovery.<\/li>\n<\/ol>\n
Step 1: Pointing a new AWS instance to an Old SnapShot<\/h2>\n
The general idea here is that an AWS instance is analogous to an old school bare-bones server (memory, motherboard).\u00a0 The SnapShot is analogues to the image of the hard drive that needs to be restored.\u00a0 The way I found it works is first you bring up the new “computer” with a new “hard drive” and make sure it works.\u00a0 Then you shut down the computer and swap out to the old hard drive image.\u00a0 I think AWS either created an extra step, or I found an odd way of restoring backups, but it worked so that is how it is documented here. Before embarking on this endeavor, I did some research. In short:<\/p>\n
- \n
- Create a compatible ES2 instance of your previous system<\/li>\n
- Start the new EC2 instance, then shut it down.<\/li>\n
- With is shut down, right-click and detach the Volume\n
- \n
- you need to determine where the new HD is mounted (\/dev\/sda, etc.)<\/li>\n
- you will need the instance ID to link the saved HD<\/li>\n<\/ul>\n<\/li>\n
- From your previous \u00a0your Snapshot, right-click and create a new Volume<\/li>\n
- Assign that Volume to the new instance ID with the same mount point as before<\/li>\n
- Restart the new instance that now runs the old HD<\/li>\n<\/ol>\nOf all of the articles I read, these two were the most helpful:<\/div>\n
https:\/\/amimoto-ami.com\/2014\/10\/03\/create-snapshot-restore\/<\/span><\/u><\/a> http:\/\/blog.ravitezu.me\/error-starting-aws-ec2-instancehttp:\/\/blog.ravitezu.me\/error-starting-aws-ec2-instance<\/span><\/u><\/a><\/p>\n
Here are some issues that I ran into:<\/h3>\n
Issue 1:\u00a0<\/strong>Make sure you use the same security groups.\u00a0 I have more than one profile and my default is not my WordPress EC2 instance.\u00a0 This means my local public and private keys were a mismatch and I could not log in until I corrected that. <\/em><\/p>\n
Issue 2:<\/strong>\u00a0If you try to connect to the new system via SSH, etc, the IP address will be different than it was before.\u00a0 DO NOT CHANGE THIS OR THE Route 53 CONFIGURATIONS!\u00a0 Instead, use the Elastic IP address feature to\u00a0set the new IP to\u00a0report to the outside world as\u00a0the old one.\u00a0 \u00a0I spent about 30 minutes trying to log into WordPress, but the system kept getting mixed up between old and new IP address.<\/em><\/p>\n
If, you did somehow change IP addresses on the server and do not have the Elastic IP configured, you can read how to repair the WordPress database on my old post here<\/span><\/u><\/a>.<\/em><\/p>\n
One those were fixed, I was able to see an old version of the server.<\/p>\n
Step 2: Upgrading the AWS Server via Package Management<\/h2>\n
I love this step. To upgrade wordpress, GitLab, and the entire AWS web server, simply log into the Linux server and type:<\/p>\n
#sudo yum update<\/pre>\n
I would like to say that it has never failed me, but there was that one time where I had to manually patch a GitLab file.\u00a0 I wrote a whole blog post about it, but that was lost in the crash.\u00a0 Luckily, GitLab was very responsive to the issue and had already pushed out a new build. To summarize, the old post, if you have an issue with GitLab, search their page:<\/p>\n
https:\/\/gitlab.com\/gitlab-org\/release-tools\/issues<\/span><\/u><\/a><\/p>\n
Step 3: Getting WordPress Operational Again<\/h2>\n
Step 3a: Resetting the WordPress password<\/h3>\n
This is an optional step for those that remember what their password was a year ago.\u00a0 However, I did not.\u00a0 This means that I needed to reset the WordPress password of my blogging account gscott.\u00a0 While there are web-based tools such as phpMyAdmin, I do not try to expose more admin tools to the web than I need this means I needed instructions for resetting the password via MySQL directly.\u00a0 After some googling, I found this article to be the most helpful:<\/p>\n
https:\/\/codex.wordpress.org\/Resetting_Your_Password<\/a><\/p>\n
Step 3b: Upgrading WordPress Themes and Plugins<\/h3>\n
Once the base system was up and functional, I needed to upload the latest theme and import\/export tools.\u00a0 Here are the basic instructions:<\/p>\n
Adding New Themes Manually (FTP)<\/span><\/h4>\n
- \n
- Download the Theme archive and extract the files it contains. You may need to preserve the directory structure in the archive when extracting these files. Follow the guidelines provided by your Theme author.<\/li>\n
- Using an FTP client<\/span><\/u><\/a> to access your host web server, create a directory to save your Theme in the wp-content\/themes<\/tt> directory provided by WordPress. For example, a Theme named Test<\/b> should be in wp-content\/themes\/test<\/tt>. Your Theme may provide this directory as part of the archive.<\/li>\n<\/ol>\n
Here is the full content of the link:<\/h4>\n
https:\/\/codex.wordpress.org\/Using_Themes#Selecting_the_Active_Theme<\/span><\/u><\/a><\/p>\n
Here is what I did:<\/h4>\n
I recommend giving the directory two folders.\u00a0 One for the old theme and one for the new one.<\/p>\n
After I got the new theme to my site, I simply extracted it to a new theme folder:<\/div>\n# unzip customizr.3.4.22.zip -d \/var\/www\/html\/wp-content\/themes\/customizr_3_4_22\r\nArchive:\u00a0 \/usr\/share\/wordpress\/wp-content\/themes\/customizr.3.4.22.zip\r\n\u00a0\u00a0 creating: customizr_3_4_22\/customizr\/\r\n\u00a0 inflating: customizr_3_4_22\/customizr\/comments.php\r\n\u00a0 inflating: customizr_3_4_22\/customizr\/footer.php\r\n...\r\n\u00a0 inflating: customizr_3_4_22\/customizr\/style.css\r\n# ls\r\ncustomizr\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 customizr_3_4_22\u00a0\u00a0\u00a0\u00a0\u00a0 index.php\u00a0\u00a0\u00a0\u00a0\u00a0 twentyfourteen\r\ncustomizr.3.3.26.zip\u00a0 customizr.3.4.22.zip\u00a0 twentyfifteen\u00a0 twentythirteen<\/pre>\n
Doing so will give you both versions of the theme to choose from:<\/p>\n
![\"Customizr\"](\"http:\/\/52.24.147.87\/wp-content\/uploads\/2016\/08\/Customizr-300x156.png\")
<\/a><\/p>\nIt should be noted, I had to change my sidebars and other widgets back in the new version, but overall the process took less than 10 minutes.<\/p>\n
Similar to above, the import\/export plugin also needed to be updated.\u00a0 It was placed in the wp-content\/plugins<\/span> directory.<\/p>\n
# mv wordpress-importer\/ bob\r\n# unzip wordpress-importer.0.6.3.zip\r\nArchive:\u00a0wordpress-importer.0.6.3.zip\r\nwordpress-importer.0.6.3 packaged\r\n\u00a0\u00a0 creating: wordpress-importer\/\r\n\u00a0 inflating: wordpress-importer\/readme.txt\r\n\u00a0\u00a0 creating: wordpress-importer\/languages\/\r\n\u00a0 inflating: wordpress-importer\/languages\/wordpress-importer.pot\r\n\u00a0 inflating: wordpress-importer\/parsers.php\r\n\u00a0 inflating: wordpress-importer\/wordpress-importer.php\r\n# ls\r\nakismet\u00a0 bob\u00a0 hello.php\u00a0 index.php\u00a0 wordpress-importer<\/pre>\n
Again, WordPress was great about installing side by side.\u00a0 Once I have shown that the importer functions correctly, I will detele the “bob” directory.<\/p>\n
Step 3c: Restoring and Replacing Old Content<\/h3>\n
The Tools menu in WordPress offers an import\/export feature.\u00a0 After I imported my old blogs, I had to go back over each one and review the content.\u00a0 Some links were broken, other images were missing.\u00a0 I also had to redo the new style that I rolled out for better search results.\u00a0 Overall it was not too bad due to an entire site crash, but it took some time.<\/p>\n
Step 4: Restoring GitLab<\/h3>\n
The GitLab server\u00a0is still up, but only has test repositories.\u00a0 I created a blog post of how to sync local repositories back to the GitLab server.\u00a0\u00a0 That part went off without a hitch, until I tried to restore my default labels <\/a>and reconfigure the server after the upgrade.<\/p>\n
While doing this, I also did a “sudo yum update” – which updates all of my packages.\u00a0 most items worked well, however GitLab failed.\u00a0 It looks like I did one too many things at the same time (again).<\/p>\n
When GitLab tries to start, but cannot, it creates a weird “Oops” page.<\/p>\n
![\"GitLab](\"http:\/\/www.stonemillkids.com\/wp-content\/uploads\/2016\/09\/gitlab_502_error-287x300.png\")
<\/p>\nAfter 8hrs of googling, I came up with a solution!\u00a0 It was really simple actually.\u00a0 You see, I had copied my original file via Ctrl-C + Ctrl-V.\u00a0 Gitlab could not interpret it for some reason and unicorn was taking up 100% of my CPU.\u00a0 To correct the problem, I simply manually retyped the file inside my favorite Linux editor.\u00a0\u00a0I guessed what I needed to do because if typed “gitlab-ctrl tail” which gave me a complete log of everything going on.\u00a0 I found that every time I started, I was getting an error in issues_labels.rb on the first line that I changed… which was disovered by taking the default file, then changing one just my colors, then just my lables.\u00a0 – It was bascily an error bubble sort on the file with at restart of GitLab every iteration.\u00a0 My four goto commands were:<\/p>\n
\u00a0# sudo vi \/opt\/gitlab\/embedded\/service\/gitlab-rails\/lib\/gitlab\/issues_labels.rb\r\n\u00a0# sudo gitlab-ctl restart\r\n\u00a0# top\r\n\u00a0# cat \/var\/log\/gitlab\/unicorn\/unicorn_stderr.log<\/pre>\n
I also had a separate terminal running<\/p>\n
# gitlab-ctl tail<\/pre>\n
Each time I saw an error, I would change the file on that location and restart.\u00a0 It was slow progress, but eventually GitLab was able to restart without errors.\u00a0 As such, I am posting my issues_labels.rb<\/a>.<\/p>\n
\u00a0Step 4: Finding Out What is Missing<\/h2>\n
Step 5a: Reading all my old Blogs and Taking Notes<\/h3>\n
On my site, there were tons of missing images.\u00a0 The backup only saves text.\u00a0 Images are (I believe) stored in MySQL, so they were not backed up.\u00a0 As such, I had to import all of the old images again.<\/p>\n
There were also pages that I renamed over time. They showed up as “duplicates” – meaning the same page, with two different titles.\u00a0 I had to compare them side-by-side and manually merge them.\u00a0 Not fun, but doable because I generally took the later post.<\/p>\n
The one big issues I saw was the import DID NOT\u00a0<\/em>\u00a0 Import pages with the same name.\u00a0 This means that if I updated a page, but it had the same name, I would not get the content.\u00a0 If I was not pressed for time, I would have deleted all of the pages and re-imported them.\u00a0 Since I was not very active blogging between posts, I simply read the pages that were there and made corrections for grammar, clarity and content.\u00a0 Not the safest thing to do, but it was all I was willing to stomach after all of the other issues I had dealt with.<\/p>\n
Step 5b: Asking Google to Reindex the Site<\/h3>\n
Now that the site is back to where is was before, or at least a reasonable facsimile of it, I need to let Google know so it can reined the site.\u00a0 If my backup was identical to the site before, I would not see this as an issue.\u00a0 However, I lost and had to recreate data, so I expect some things to be different.<\/p>\n
https:\/\/support.google.com\/webmasters\/answer\/6065812?hl=en&ref_topic=4617736<\/span><\/u><\/a><\/p>\n
https:\/\/www.google.com\/webmasters\/tools\/submit-url?continue=\/addurl<\/span><\/u><\/a><\/p>\n
Step 6: My New Backup Strategy<\/h2>\n
Looking online, there does not seem to be a cost effective (automated)\u00a0backup strategy for a single server.\u00a0\u00a0Right now, my bill runs about $9\/mico instance I use and about $0.5 (50 cents) for storing my backups.\u00a0 As such, I simply going to manually make the backups as I need them.\u00a0 Now that I know how to\u00a0backup and restore the SnapShots, I feel a lot more comfortable with the cloud storage I am using.<\/p>\n
My next logical step would be to also AWS to backup my local PC, but I am currently happy with Microsoft’s One Drive and the AWS hosted GitLab server that I run.<\/p>\n
In short, we will keep this Status Quo for now… but I will be creating a snapshot right after I finish the post.<\/p>\n
Step 7: Write Everything Down<\/h2>\n
The good part about blogging about what happens, is it creates a natural log of how to fix it.\u00a0 The only issue I have run into is that when the site crashes, so does the blog.\u00a0 Luckally, my local\u00a0XML backups from WordPress have aways given me enough content to get back to a functional server fairly quickly.<\/p>\n
My next logical step here would be to\u00a0create a single, easy to\u00a0find page, that describes\u00a0the\u00a0steps I need to take so I do not have to search through the\u00a0site’s entire XML file.\u00a0 I’ll add that one to\u00a0my backlog on Trello.<\/p>\n
Now that we are Done<\/h2>\n
If you want to delete the old snapshots or AMI instances that use them, AWS has a couple of good articles.\u00a0 I would, however, suggest creating a new snapshot of the newly working system before deleting anything.\u00a0 Also keep in mind that AWS does incremental updates, meaning the 1st backup is the entire drive and each additional snapshot only has the differences.\u00a0 Anyway, here are links to the AWS documentation:<\/p>\n
http:\/\/docs.aws.amazon.com\/AWSEC2\/latest\/UserGuide\/ebs-deleting-snapshot.html<\/span><\/u><\/a><\/p>\n