Quote:
Originally Posted by pdurrant
Is your RAID a mirrored raid?
|
Yes, (mirrored) we are considering that and we don't see a viable alternative. We've thought about truning a computer into a file server, but I need more levels of complexity like I need a hole in my head.
Quote:
|
How about replacing one of the disks with a fresh disk, letting it rebuild in the background, while you post the removed disk to a trusted location. Then do that again in whatever time frame seems good to you. When the trusted location receives the latest disk, they ship the earlier disk back to you to be reused. You'd need four disks instead of two. Two would always be in use, one would be in the trusted location, and one would be in transit, or waiting with you to be reused.
|
The problem with that is, it's a snapshot. There are no incremental backups. It's all or nothing and
if you crash, and your snapshot is from a week ago...you're hosed. At least,
I would be.
While it's true that I can restore files from Dropbox, as I have a commercial account with 180-day restoration capabilities--here's the thing. I'd have to KNOW that I needed to restore it, because it was updated after the snapshot. I mean...I have just around 1M files in the DB. I wouldn't know what was updated versus what wasn't to save my damn life. Keep reading, it gets murkier....
Quote:
|
Disaster recovery is just the time to get replacement hardware, and the off-site disk, and rebuild the raid from it. probably a lot less than the two week needed to download from from the internet!
|
I agree with you there.
Quote:
|
With incremental backups to the cloud storage, you could also recover the work done in the time since the last offsite backup was sent, in a lot less time than getting all the data down from the cloud.
|
Yes, but...if I pop in a new RAID drive--remember, this is Dropbox we're talking about here--the older dates will OVERWRITE the data on the DB.com website, which is meant to be the incremental backups.
I just ran into DB's limitations, in a very unpleasant way, finding out that if you uninstall DB and reinstall it, despite representations from DB support to the contrary, that it overwrites the goddamned dates for the folders. So, everything I have now, folder-wise, is date-stamped with the time and date it re-installed, NOT the time and date that the file or folder was actually created or modified.
So, my fear is...and think this through with me--I have a crash. I have the RAID in storage. I pull it out and let's say, for S&G's, that it's 5 days old. I reinstall the RAID and it overwrites all the dates on DB. That in turn synchs up to the Cloud, which in turn ruins all the incremental data.
Right? Isn't that what happens? I mean, DB's real down-n-dirty is heavily hidden. It's nearly impossible to get the real skinny on what it does or how or the sequence, but it's not doing what they say it should do and you can only--get this!--restore files with their original dates through their new (utterly useless) desktop app. Which is a NIGHTMARE to use. I mean..
seriously? I'm meant to restore
a million files, through their desktop app, instead of simply reinstalling the DB *software* and re-synching the files? Why the hell would the folders re-date? It makes NO sense.
Quote:
Originally Posted by PeterT
Years ago I seem to remember where I worked using the remove a drive from a raid1 array as a means of backup on a production environment.
|
Right and that's how we thought about it, but I keep running into this problem, trying to think around HOW not to utterly screw the pooch on the dates and how DB works.
Hitch