As a former Drobo deployer, I strongly advise against their devices. +1 for Synology.
-- Espi On Mon, Jan 12, 2015 at 6:30 PM, J- P <[email protected]> wrote: > I've been providing offsite backup since '08 to my clients ranging from a > few hundred MB's to a few TB's on the higher end, and although I'm a tiny > fish in the pond, I can tell you that 17tb (depending on file types and > compression) can run them into the tens of thousands per year. > > Even the big boys like Carbonite are about 2k per year for a 1TB- > > Of course there is always the argument of TCO associated with using your > own hardware and so on, but if its for backup you dont NEED the latest > 16core cpu's with 512GB of ram. Heck for a few grand I can build a 24TB > box, or you can even buy prebuilt 24/36TB devices (Synology , Drobo etc) > > > > https://www.google.com/search?q=24tb+server&ie=utf-8&oe=utf-8 > > http://www.bhphotovideo.com/bnh/controller/home?O=&sku=759605&gclid=CJmEzvz0j8MCFchr7AodjAYAyA&Q=&is=REG&A=details > > > > > ------------------------------ > From: [email protected] > To: [email protected] > Subject: RE: [NTSysADM] Backing up between main office and remote site > Date: Mon, 12 Jan 2015 16:50:39 -0700 > > James, you make some good points. > > > > 1. The initial idea would be to seed the backup device and then > drive it to the remote office located 2 hours away. Then after setup the > incremental backup should take over. I know restoring the data will take > time if all of it is restored at one time. But breaking it down to > individual servers or current data would help the restore process. > > 2. Cloud storage right now is being considered because everyone > seems to be talking about it. He mentioned cloud as an additional option. > Currently thinking Microsoft's Azure. > > 3. I don't think they have a DR process in place. But I think it is > something they are considering because of this request. They may be > thinking that with some of the servers being VMs they can be restored > quickly. But like you said, can they get to the equipment to restore them? > > 4. The current setup is unknown. If they agree to an assessment and > inventory, I will have a good understanding of what is there. They will > also. Since it didn't sound like they have something like that in place > now. He mentioned how much trouble it was looking for accounts and > passwords to change when the last IT guy just quit. And he's not sure he > got all of them. > > > > Art DeKneef > > Avanti Computers > > Mesa, AZ > > 480-649-4430 Office > > 480-529-4430 Mobile > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *James Button > > *Sent:* Monday, January 12, 2015 4:08 PM > *To:* [email protected] > *Subject:* RE: [NTSysADM] Backing up between main office and remote site > > > > Not having done such corporate backups for a long while I am not going to > suggest facilities, but pose some things to consider: > > > > 17TB is a high volume to run overnight backups on - so can you get away > with just incrementals > > With a consolidation of the incremental saves as an after that - daily > task. > > USB3 - SATA3? Drive speeds mean it will take ???days to just reload that > 17TB using locally attached media > > > > Will cloud backup allow a reasonably fast restore /recovery of the > operational environment > > Is that cloud backup secure and safe - as in who owns the facility, the > datastore hardware and the links to that service provider's systems and > then their datastore > > When (OK if) the datastore owner goes bust what happens to the drives > containing your data, and to your data itself > > > > If using physical transport of backup media - avoid having the same > transport vehicle do both the return of the old copies and the transport of > the new - tends to lead to a shortcut where both copies are in the same > location at the same time - as in your main location's car park. > > > > And ... what is the disaster recovery process ? > > > > Consider if there is a fire in the main server farm area and the building > (partially) collapses > > > > 1 site I worked at found that the backup documentation, current backup > storage devices and master passwords, recovery plan and authorisation codes > - contacts etc. were in a safe in the middle of the building. > > > > That was noted by 'Management' when I finally managed to persuade them to > do a proper disaster recovery exercise - On one long-holiday weekend, > senior IT management stopped all IT staff from accessing the building with > the statement - this building is not to accessed - now go and get the IT > working again! > > > > The panic starts with - can you contact the appropriate people at the > standby site - when you don't have their contact details! > > > > A 2 hour firesafe is not much good if there is heated concrete around it > for a day, and then it takes several more days to get enough of that debris > - concrete etc. moved to be able to extract the safes. > > > > (It was also discovered that the Halon suppressant system had not been > filled) > > > > So I'd start with some requirements assessments - as in what is essential > for the corporate front to the outer world > > Then some minimum time calculations. > > Also - having recreated your systems what processing will be needed to > achieve a new backup set from which your processes will be compatible with > the restore process again > > As in will you need a full backup of the 17TB before you can go to just > incremental saves again? > > > > Also - what is the exposure while having the Current (only?) backup set > in the same location as the server farm being rebuilt. - and maybe even > attached to the same hardware driven from the same power supply > > > > I recently lost a system, OS drive, data drive & the drive the data was > being backed-up to, - the PSU gave up! > > Then we found that the prior backup was not readable - probably due to > problems with that PSU that had not become bad enough to be noticeable when > that backup was being taken . > > Yes it was noticed when it smoked and the system stopped! > > > > JimB > > > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Art DeKneef > *Sent:* Monday, January 12, 2015 7:53 PM > *To:* [email protected] > *Subject:* [NTSysADM] Backing up between main office and remote site > > > > I am asking for feedback from those that backup between multiple sites. > What were the good things and what would you do different? First time I've > had to look at this in a very long time. > > > > Talked with a potential new client looking to backup up between the two > offices and possibly cloud backup. Current data size is estimated at 17 > TBs. A disaster recovery type of thing. Besides have the backup local > another copy is off-site. > > > > Main office has several Windows Server 2008 physical servers along with > 15-20 virtual servers. They are running VM Ware (unknown version). Included > in the mix is an Exchange Server (probably 2010), couple SQL Servers > (unknown version), file and print and AD. The remote office has a few > servers. Each site is on a fiber network but speed is unknown at this time. > He is checking. > > > > Their previous IT guy just quit so they asked for a proposal to go in and > document the network and implementing a remote backup solution. Right now > we're focusing on this backup solution but I'm sure it will change as we > get further into our discussions. > > > > I could use a couple of enterprise NAS devices or put in a couple of > Server 2012 R2 servers as a storage and possibly turn on de-dup to reduce > data transfer size. > > > > Thanks for the help. > > > > Art DeKneef > > Avanti Computers > > Mesa, AZ > > 480-649-4430 Office > > 480-529-4430 Mobile > > >
