Link to home
Start Free TrialLog in
Avatar of it_medcomp
it_medcompFlag for United States Minor Outlying Islands

asked on

Backup Strategy for large amounts of data?

Curious what others are doing for backups..... I am about to take a sledgehammer to our current setup, and am curious what other people use and what backup strategies they employ. Cloud is not an option for our firm- our backups to tape can accommodate storage. Currently, we have a daily incremental backup, a weekly full backup that expires after 5 weeks and a monthly backup that never expires and is retained indefinitely. Currently, I have to schedule backups to run every Friday and then watch them all weekend because the backup software randomly marks our full backups as "superseded" (Just started this a month ago), and support was never good from this vendor. We have in-house Exchange, file servers, in-house SQL, an AD domain, and of course file servers. Almost our entire infrastructure is Hyper-V. Total amount of data is about 20TB. I'm more interested in strategies to safeguard the data than an actual product. Should I consider changing the weekly backups to only backing up data that has changed in the past 30 days, and have the monthly be all data? I'll take any suggestions or perspectives on the best way to do this.

Thanks!
Avatar of Philip Elder
Philip Elder
Flag of Canada image

One option that allows for a reuse of existing hardware would be StarWind's Virtual Tape Library (VTL) that is in turn tied in to BackBlaze for off-site backup replication. The two together are about the best deal going cost wise.

VTL integrates into existing backup setups as it is a "native tape library" to the backup software. It integrates really well with Veeam.
Avatar of Kimputer
Kimputer

Actually, my backup strategy is basically the same as you described. Having a too long period of diff/inc backups can cause problems also, so weekly is fine.
Typical backup operations used by almost all businesses are full backups (usually weekly), incremental backups (usually daily).
Avatar of it_medcomp

ASKER

That's where I started. The problem is that our backups exceed the backup windows at times, but even when they fall inside them, the software screws up- backups fail, or full backups fail without sending notifications, our VP of IT (Very hands-on BTW)  thinks we back up too much, I don't think we back up enough... the list goes on. I am going to use a different solution because we have always had trouble with this program and their support, and their solutions are always the same- spend a week or two troubleshooting the issue, their correspondence is always out of date and they send emails to the wrong address and phone calls to the wrong numbers and ask for the wrong person.... even though we have kept our profile and tickets updated with correct information..... Plus, the hardware we were using was not suited for this application.... so I am replacing buggy software and horrible hardware with software that will work and with hardware that has proven itself in reliability and performance and with industry-touted software. There are a number of reasons we don't use cloud backups that I am not going to go into here, and disk backup was a miserable failure, so tape it is!
 Before we go into a new software, I need to refine my strategy. Daily incrementals are negligible and reliable. Weekly backups of the last 30 days should cover us, and then we would have a monthly backup that contains all the data anyway... I am curious if anyone else has a similar strategy, and of any caveats or suggestions to further pare back backups (Shorter backups are less likely to fail).
".... The problem is that our backups exceed the backup windows at times..."  
If you can´t finish the backup inside the backup window, you need to upgrade your hardware, backup software and I/O communication links (Fibre, Giga ethernet). You can reduce the amount of data to be backed up, consider employing a backup application that uses deduplication technology. Another option is to archive old data or data that is not regularly accessed to a data archive: backup only active data.
Hi
you may consider data de-duplication software/hardware to be applied in your environment side by side to backup solution, and this will lead to a high drop in data sizes.
I would backup everything to DISK.. first.. .then dump that to the TAPE.

Backup 2 disk, is waaaaay faster... and it will already be compressed when you send it to the tape, which is also faster.
I used to use regular USB 3.0 attached drives on the backup server, create the B2D folders for each server to be backed up concurrently on seperate drives.
Then from there, I would dump each of those folders to the tapes.

Some other things you may consider...
1. Create a "backup network"... a separate switch that each server has a connection to, and your backup server resides on.  This will completely segment the backup traffic from your network.
2.  Use more than one backup server to run the largest backups concurrently.  This also reduces the chances that you backup nothing in the event the backup server itself has some issue.
3.  Your tapes should be sent with a courier off site on a regular schedule, and rotate them as you see fit to your backup strategy.  Last weeks backup should never be onsite however.
4. Make sure that no anti-virus software is scanning on any server involved in backup process, while the backups are running.  Make sure your backup to disk folders are excluded from being scanned.
5.  Move in-house services that don't need to be in house, to the cloud, if it's feasible.  Cloud backups are included in most cloud services...with redundancy.
6. If Exchange is taking forever to backup, reduce the size of mailboxes and create a policy to cleanup items older than _____ days/months ..and move them to local file storage on the client. (.PST/.OST)
7. Stop unnecessary processes and services that are CPU, memory, or bandwidth intensive, on every server involved in the backup process during the backup window.
8. ARCHIVE things that do not need to be continuously backed up and are never going to change...and exclude them from the backup process.
9. TEST your restore process.  Make sure critical items can be restored as expected and you are familiar with the restore process...which should also be documented along with documentation of your backup strategy as a whole.
VTL is a good compromise. :)
Is this a duplicate, i thought we already had a thread on this?
Wow.  Reading the suggestion shows my exact strategy... began with B2d but none of the hardware was adequate- the Drobo offerings are at best unstable. Symbology was the same experience, and I was using iSCSI models on a physically separate network. I was able to deal with the transfer speed by getting a SAS-attached robotic LTO8 library. Because our environment is in transition, I had a server with 5TB of storage that I used for my lowest data speed transfers... then backed it up. But I am still pushing my backup windows. Even with 6500 data transfer rate on average (roughly triple my peak data rate on the iSCSI network) I'm pushing windows and cannot backup my email server in time. What happens when I back up only 90 days worth of changes is that the backups save less data and take the same amount of time. The transfer rate drops and that is why. Any idea how to solve this?
If throughput drops over time.. im my experience  it usually indicates a memory leak or network device bottleneck.  Some other software process could be causing this... like an anti virus realtime scan process... for example.

Also...Exchange brick level backup is notoriously slow.. and honestly unnecessary on a day to day basis.  Backup the entire db throughout the work week and do brick level on the weekend... if your corporate backup policy permits.
I have not been backing up Exchange because we have email archivers so the messages would be retrievable... but I need to start backups so the translog purge and things shrink down. The problem with backing up Exchange is that I have to run incremental backups every night and a single Exchange backup takes at least a couple of days. It's about 8TB of data and it's not fast... and the problem with tape backup is that I can only run a single backup at a time. So if I back up Exchange, I don't get my incrementals. My biggest problem I think I have is the I am using BackupExec... and right when I was about to stop monitoring the schedules, full backups began changing status to Superseded randomly at first but now I have 8  backups and at least 6 of them are marked at superseded as soon as they start. So now I spend Friday thru Sunday monitoring backups and starting them manually. Now backups have simply stopped running. Like it sits there in an active queued state, even tape inventory jobs. Would I have these same issues with Veeam? My environment is 90% virtual HyperV. I'm running this on a 2012r2 bare metal server which contains 4 onboard nic ports and a 4 port expansion card as well as the SAS2 card that is connected to the tape library.
Did you look for any updates on the tape drive firmware?  ... just thinking of personal experience this has happened to me before.
Resolved the issue. The solution was simple- just drop the BE database along with its months of auditing history and rebuild my storage configurations, backups, and schedules from scratch. Switching away from this horrible product can't happen soon enough. So, part of my question that I believe got buried- Right now, if I backup a monthly backup, it will contain all data on the network. Then if I backup weekly backups that only contain the last 90 days of changed data, will Veeam run the same way as BackupExec, where it takes 75% of the time to back up 20% of the data? My backups were up over 6TB on my main file server, so I told to exclude files on the weekly backups older than 90 days, and the backup now happens at 800MB/Min-1200MB/Min instead of 6500MB/Min, even though the backup is now 1.3TB. With Veeam, will I have the same thing happen?
For the Exchange situation:
Diskshadow 
Add volume d:
(optional, add one line for each additional drive to include) 
Add volume X:
Begin Backup
Create
End Backup

Open in new window

NOTE:
1: This "tricks" Exchange into consolidating the logs. Can be done for SQL as well.
2: Must be run in an elevated session
3: Backups are critical to making sure data is recoverable! Period.
4: Can be scheduled to run once an hour or two.
5: vssadmin may be needed at some point to delete the cached snapshots if any.
I’m disappointed I didn’t think to tell you about database maintenance for BE because that’s another issue I ran into with BE but its been a ling time since I’ve used it.

See this link
https://support.symantec.com/en_US/article.HOWTO76451.html
This question needs an answer!
Become an EE member today
7 DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.