August 2, 2012 at 11:44 pm
Comments posted to this topic are about the item The Copy Cat Poll
August 3, 2012 at 3:24 am
Lots of copies..This is all for 1 database...
production application:
Main server:
primary copy of the database
backup image from previous night
DR/HA server:
copy of the database
UAT server:
2x copy of the database
reports systems:
vm report server:
copy of the database
3x backups
physical report server:
copy of the database
1x backup
vm report server (test system):
copy of the database
1x backup
backup servers:
entire VM report server backed up
entire physical report server backed up
entire vm test system backed up
application servers back up directly to tape so not included in backup servers.
in all 21 copies of the database plus a partial (annonymised) copy on my workstation that I sometimes use for dev.
I think it's about time we reviewed our backup stratergy...
Ben
^ Thats me!
----------------------------------------
01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
----------------------------------------
August 3, 2012 at 4:18 am
For each Application we have
1x Copy on Production Server
10x Days Backups on NAS
1x Copy on UAT Server
1x Backup of UAT on NAS
1x Copy on Recovery PC (All DB's restored from NAS BAckups to here and DBCC Checked each day)
Depending on Dev work
1x (anonymised) copy per developer PC
August 3, 2012 at 5:08 am
Its 8 for databases for our main production database
Main Production System
Production Support
QA
UAT
Dev
Internal Training
External Training
and a nightly refreshed Reporting DB
If you include backups
3 x Nightly Full backups on Disk for each DB bar the Reporting DB + 1 months on tape + 2 years of monthly tapes
Which I make (3x7) + (31x7)[as July has 31Days!] + (24x7) + 8 = 414
That was a bit of a surprise for my boss! He had guesstimated 40 odd
Also coming soon a DR solution which will be a mirror of our entire IT Universe and as many nightly snapshots of individual servers as we wish
https://blog.robsewell.com Its where I blog
SQL Community Slack Channel https://sqlps.io/slack
The Best PowerShell Module for the Modern SQL DBA https://dbatools.io
Data South West User Group http://sqlsouthwest.co.uk/[/url]
August 3, 2012 at 5:50 am
We have 66 TB of data. Developers routinely ask for a copy of a production database, but most of the application databases are over 2TB so the request is denied. All non-production areas have a full schema, but limited data.
Backups go directly to tape and should have 3 full copies at the offsite vault.
August 3, 2012 at 6:51 am
1 Dev environment
1 Integration environment
1 Acceptance Testing environment
1 Automated Testing environment
1 Production environment
Backups weekly full, nightly differentials (unless diff is 50% size of database then take fulls), hourly transactionals
We have an ETL out to pre BI staging area which concievably can be reversed to recreate any database in that process.
187TB of data 150 plus servers, 800 plus databases
3 DBA's
Free coffee
:Whistling:
August 3, 2012 at 6:57 am
1 Production Environment
3 Full Backups + 12 Differentials + 36 Transaction log backups on the production server
1 Staging Environment
1 Full Backup copied from Production at some ponit
1 Development Environment
1 Full Backup copied from Production at some point
1 Product Research Environment (SQL 2012)
1 Full Backup copied from Production at some point
Each environment has a copy of the database on the instamce.
All backups are compressed if that matters.
August 3, 2012 at 7:16 am
1 - production
1 - mirror copy
1 - reporting server
2 - test servers
2 - development servers
@6 - backup copies on SAN
Yikes!!! I hadn't really considered the number of these puppies that have been replicated around here! 13+ copies of the production db!!! Holy redundancy batman!!! Even subtracting the copies produced by the backups, 7 copies of it seems pretty heavy - especially at around 64 GB each!
August 3, 2012 at 7:18 am
Ours is a small shop with a relatively small 3-4 GB database for our primary app.
We have 4 copies of the DB plus backups.
1 Production
1 Development\Testing
1 Training
1 out of date copy on my fully encrypted laptop so I can do development or troubleshooting work on the road if I have to.
August 3, 2012 at 7:52 am
Hm. Let's see here...
1x main production database
1x inventory management database
4x daily full backups of main production database, scattered around our servers and workstations (I'm quite paranoid about losing our data!)
1x rolling archived backup of the main production database, with appropriate log backups (this way we can roll back as far as three weeks if absolutely necessary, or just fetch old data with a restore if needed)
3x backups of the inventory management database
In addition, we have another copy of both databases captured in our nightly server backups, but I don't think restoring from that backup will properly restore the SQL Server main production database. The inventory management database is in Access, and we've had to restore that from the server backup before, so that seems to work out.
Not all that many copies, since we only have two databases to keep track of, but I'm super paranoid about data loss, so there's plenty of copies of each:-)
- 😀
August 3, 2012 at 7:55 am
We have just:
- production database
- developer database, copied from production database once a month
Backups are managed by our sysadmin and are stored god knows where. 6 developers on the project.
August 3, 2012 at 8:22 am
Jakub.Janda (8/3/2012)
Backups are managed by our sysadmin and are stored god knows where.
Scary
August 3, 2012 at 9:03 am
Main Production DB is around 3 TB, current growth rate is roughly 1 TB / year.
Total 7 copies.
We keep 5 copies online (prod, qas, dev, train, sandbox), a SAN-level mirror, and a traditional Full/Diff backup set. The Dev copy is signifanctly older/smaller but I'll offset that with the ongoing diffs. 🙂
Viewing 15 posts - 1 through 15 (of 35 total)
You must be logged in to reply to this topic. Login to reply