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)
Infrastructure & Operations
Virtualization
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.
Assignee | ||
Comment 1•6 years ago
|
||
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.
Reporter | ||
Comment 2•6 years ago
|
||
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?
Assignee | ||
Comment 3•6 years ago
|
||
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?
Reporter | ||
Comment 4•6 years ago
|
||
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?
Assignee | ||
Comment 5•6 years ago
|
||
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.
Comment 6•6 years ago
|
||
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.
Assignee | ||
Comment 7•6 years ago
|
||
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?
Comment 8•6 years ago
|
||
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)
Comment 9•6 years ago
|
||
Finished retrieving the backup.
Reporter | ||
Comment 10•6 years ago
|
||
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)
Comment 11•6 years ago
|
||
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.
Assignee | ||
Comment 12•6 years ago
|
||
Renamed to "arewefastyet.community.scl3.mozilla.com-KEEPUNTILAPRIL2019-1488534" - and moving it to our storage space in MDC1.
Assignee | ||
Comment 13•6 years ago
|
||
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.
Comment 14•6 years ago
|
||
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)
Comment 16•6 years ago
|
||
cknowles: Good to go!
Assignee | ||
Comment 17•6 years ago
|
||
Alright, powering off, I'll move it over to MDC1 this afternoon. So let me know if it needs to be reverted.
Assignee | ||
Comment 18•6 years ago
|
||
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
Assignee | ||
Comment 19•5 years ago
|
||
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)
Reporter | ||
Comment 20•5 years ago
|
||
I have heard no requests of needing the old data, I will r+ removing the old VM
Comment 21•5 years ago
|
||
I also have heard no requests for data and would like to put this behind me as well. r+
Flags: needinfo?(bob)
You need to log in
before you can comment on or make changes to this bug.
Description
•