Closed Bug 1488534 Opened 6 years ago Closed 6 years ago

get a backup of the arewefastyet.com virtual machine

Categories

(Infrastructure & Operations :: Virtualization, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jmaher, Assigned: cknowles)

References

Details

in bug 1443200 we created a new VM for AWFY, we are working to decomission it and when we have the domain name pointed at our dashboard (bug 1488533) we can snapshot the VM and turn off the service.
We are currently scheduled to turn off the SCL3 VMs on 9/13 - at which point the VM will be down, and we will be saving the "bodies" for a time post the shutdown of SCL3. At which point, the off "body" of the VM would be your backup. We intend to keep the bodies for ~30 days. So the question is around, what is the state you're hoping to preserve? If it's simply "I want the disk/conf around in case of misses" - then I'd recommend shutting the box down gracefully. If you're specifically making changes that you will want the ability to revert to, then snapshots are likely good tech, I see from the original bug that :bc has snapshot powers on that VM, and the MOC, or the virtualization folk can assist there. Let me know how I can assist.
the main goal of a backup is: 1) old data from the database if there is a need (although I am not hearing there is a need) 2) some config someone thought was running and we have no reference to it Ideally keeping a backup in storage for 6 months would alleviate all issues since we could then schedule time to boot it up and get whatever information we need. Is a snapshot easy to restore 4 months later if there is a need to pull some information from the filesystem or database?
Snapshots are kept with the VM, so it's no different from just keeping the VM. (Assuming you're not making changes between taking the snap and shutting it down.) I'll take this back to the team, and we'll see what proposals we can come up with - one question for you, what's the size of the database&config that you're looking at?
I have no idea to be honest- and the config is not well known, we are just replicating the data we can publicly find on the current webpage/dashboard. The most likely scenario is that we would like to look at some history from the database on a specific test. it sounds like a snapshot would work for us. I don't know the size of what a snapshot would be- is that easy to determine?
So, a snapshot isn't a backup. It's a snapshot in time of your VM's hard drive. After the snapshot is taken, any further changes to the system are stored in a "delta" file. Which over time grows to whatever size it needs to to store all the changes. So, the 'size' of a snapshot is a very situation dependent thing. Basically, no matter whether you have a snapshot or just a turned-off VM, we'd need to keep the VM around for the entire time span. The reason I'm asking about the size, is in case other options for storing the database/config data are available. We're still discussing options.
The most recent backup of the db is a 800MB bzipped sql dump. I also make backups of the /etc directory which is only 76K bzipped. The db is marginally bigger now but not appreciably so I think. I'll make a new one but other than storing it locally on my external drive, I don't have a good place for it. Recommendations welcome.
Alright - I think we'd prefer to keep the VM. Easier restore to service if you need it. (but hoping you don't of course.) So, looking at the VMs - I see two VMs with "arewefastyet" in their name. arewefastyet.community.scl3.mozilla.com and arewefastyet2.community.scl3.mozilla.com - which one is the one that we'll be keeping? Once we've got that, I will rename it within VC to keep notes on the proposed deletion date (now+6months) and this bugnumber. Then we're just going to keep the body around post SCL3 for that timeframe. Does that sound acceptable?
arewefastyet.community.scl3.mozilla.com is the same as arewefastyet.com so keep that one. I've stopped the workers and done a backup of the db/etc and am downloading it locally at the moment. ETA to completion is 50 minutes or so. Don't do anything until I tell you I'm finished. jmaher: so we are shutting off awfy *today*?
Flags: needinfo?(jmaher)
Finished retrieving the backup.
today is not the day, but once we resolve bug 1488533, I don't see any reason to keep it around. I imagine this week it will be shut off (and losing a couple days of data when we are already collecting it from raptor isn't so scary). Thanks for getting the database backup :bc. I am not sure if there is more to do here.
Flags: needinfo?(jmaher)
I've powered off arewefastyet.community.scl3.mozilla.com. Please vmotion it to a safe location in one of the mdc data centers. We can keep it temporarily while we make sure it is safe to delete the vm. I have a backup if the sqldump and the etc configurations.
Renamed to "arewefastyet.community.scl3.mozilla.com-KEEPUNTILAPRIL2019-1488534" - and moving it to our storage space in MDC1.
Having just arrived in MDC1 - :bc pinged me on IRC asking if we could power it up ... moving it back to SCL3 - will power up and let :bc know in IRC. And will wait a little longer before moving it back to MDC1's storage next time.
bbouvier: I now have the following: awfy-data.tar.bz2 3G ~/data awfy-repo.tar.bz2 239M ~/repo awfy.sql.bz2 809M mysqldump of database etc.tar.bz2 79K /etc/ /etc/apache2 /etc/awfy-server.config /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/crontab /etc/cron.weekly /etc/letsencrypt /etc/phpmyadmin Is there anything else you might need in the future?
Flags: needinfo?(bbouvier)
No, I think that should be enough, thanks!
Flags: needinfo?(bbouvier)
cknowles: Good to go!
Alright, powering off, I'll move it over to MDC1 this afternoon. So let me know if it needs to be reverted.
Alright, it's moved, it's marked to keep until 6 months have passed. Closing out. Let us know if you need anything else.
Assignee: server-ops-virtualization → cknowles
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED

Good morning - the 6 month timer has long passed - is there any reason why we shouldn't remove the old VM carcass?

Flags: needinfo?(joel.maher)
Flags: needinfo?(bob)
Flags: needinfo?(bbouvier)

I have heard no requests of needing the old data, I will r+ removing the old VM

I also have heard no requests for data and would like to put this behind me as well. r+

Flags: needinfo?(bob)

Feel free to kill it with fire, thanks.

Flags: needinfo?(bbouvier)

Awesome, thanks, will do.

Flags: needinfo?(joel.maher)
You need to log in before you can comment on or make changes to this bug.