SNAP 4200 Disk Upgrade

[rmp.dmd1229]

Inherited a SNAP 4200 with GuardianOS 4.4. Storage is 4x153G on RAID 5. Backup regularly.

We want to upgrade to 4 x 500. Please help on the steps. We prefer not to restore data from backup.

Thanks!

[rmp.dmd1229]

As much as we want to upgrade without the need to backup/restore, i'm assuming that it can never really done.

So essentially, here's what we need to do.

1. backup data
2. power off SNAP. remove disk on slot 2 to 4
3. put new disc on slot 2.
4. power ON and let it sync.
5. when sync is done, power off. remove disc on slot 1 and put new disc from slot 2 to slot 1.
6. Power ON. If boots fine, put all new discs to slot 2 to 4.
7. Rebuild Raid 5
8. Restore from Backup.

if these fails, I can just power off and put old discs back?

Please advise.

Thanks!

[bitor]

rmp.dmd1229, did it work?

[rmp.dmd1229]

We followed a different process:

1. backup data
1.5 Delete shares, volumes, and raid arrays
2. power off SNAP. remove disk on slot 2 through 4
3. put new non formatted disc on slot 2.
4. power ON and let it sync. (about 10 minutes from startup)
5. when sync is done, power off. remove disc on slot 1 and put new disc from slot 2 to slot 1.
6. Power ON. If boots fine, put all new discs to slot 2 to 4.
6.5 let all drives sync. (about 10 minutes)
7. Rebuild Raid 5
8. Verify/Restore Snap server settings
9. Restore from Backup.


But step 4 did not work. Old disk did not sync with new disk. We did a fresh install.
Was able to build the RAID 5. new size 1.36Tb

We stopped restore of data (since we noticed CPU and Mem usage is high). Restarted (we probably should not have done this). Syncing starts again but takes forever. more than 2 hours passed and still 0% completed.

Is this normal ?

[bitor]

rmp.dmd1229,

Some of the min. requirements for upgrading to larger drives are:
1.) Having GOS 4.2 or higher
2.) Having the GOS file 4.2 or higher to install
3.) Having 1GB of memory or higher
4.) Having the original drives. I assume yes on this one.

Do you have these min. requirements ?

And yes "stopped restore" was not a good thing. You will have to start all over again by wiping the new larger drives.

Originally Posted by rmp.dmd1229

We followed a different process:

1. backup data
1.5 Delete shares, volumes, and raid arrays
2. power off SNAP. remove disk on slot 2 through 4
3. put new non formatted disc on slot 2.
4. power ON and let it sync. (about 10 minutes from startup)
5. when sync is done, power off. remove disc on slot 1 and put new disc from slot 2 to slot 1.
6. Power ON. If boots fine, put all new discs to slot 2 to 4.
6.5 let all drives sync. (about 10 minutes)
7. Rebuild Raid 5
8. Verify/Restore Snap server settings
9. Restore from Backup.


But step 4 did not work. Old disk did not sync with new disk. We did a fresh install.
Was able to build the RAID 5. new size 1.36Tb

We stopped restore of data (since we noticed CPU and Mem usage is high). Restarted (we probably should not have done this). Syncing starts again but takes forever. more than 2 hours passed and still 0% completed.

Is this normal ?

[Chewie]

I've also upgraded my 4200 like rmp.dmd1229. It's been about 36 hours and the RAID 6 resync is at 13% with an estimated time remaining of 8 days. The stock WD1600BB's took about 6-7 hours to complete a fresh build and resync if I remember correctly, this current resync seems a bit slow to be "normal." The Browser GUI and serial console are virtually unusable. The Event Log is also clean of hardware warnings or errors.

So I second rmp.dmd1229's question ...

Originally Posted by rmp.dmd1229

Is this normal ?

Any help would be greatly appreciated.

Thank you

Current configuration:
Snap Server 4200
RAM: 3GB
GOS: 5.2.056
4 x WD5000AAKB

I have all the original hardware plus the current full install image.

[bitor]

No, in short it is not normal. You will have to start over again from the beginning. I'm going to post the procedure from my notes.

"power up" and "shut down" means all the way on and off, not just a warm boot

use Master/Single NOT Cable Select

Backup all data -then-

Turn off ALL service ...AV, Shapshot,etc.. -then-

Check the other new drives for errors using(HDD Regenerator,Spinrite,etc.)... -then-

Wipe the new drives completely... -then, and only then-

With the 1GB installed;

1. power your unit up with the old drives.
2. break any raid arrays.
3. install GUS Guardian OS 4.2 file or higher if you have something below GOS4.2. If not then skip this step
4. build a new raid array (to ensure proper function of the unit).
5. break any raid arrays again.
6. shut the unit down.
7. remove old drives 2, 3, and 4.
8. install one new CLEAN ERASED drive in slot 2.
9. power up the unit and wait 15 to 20 minutes.
10. shut the unit down.

11. remove old drive from slot 1 and put the new drive from slot 2 into slot 1.
12. power up the unit with only the single new drive in slot 1.
13. ensure proper function of unit.
14. shut the unit down.
15. install remaining new CLEAN ERASED drives in slots 2, 3, and 4.
16. power up the unit and wait 15 to 20 minutes.
17. clear the logs.
18. shut the unit down.
19. power up the unit (cold start) and check logs for errors.
20. reinstall GUS Guardian OS 4.2 file, whichever you used originally.
21. shut the unit down after complete reboot from OS install.

22. power up the unit.
23. build your raid array (should take 3 to 5 hours).
24. done.


If this doesn't work, you have bad hardware somewhere. My guess would be either one of the new drives still, or a sled cable, or sled.

Good luck and let us at the forum know if it worked.

bitor

[Phoenix32]

Originally Posted by bitor

I'm going to post the procedure from my notes.

Your notes meaning copy of procedure provided by Phoenix!


Note: It is common practice (and courtesy) to provide credit to the original author when using their material.

[Chewie]

Thank you guys for the information!

rmp.dmd1229, I'm sorry for hijacking your thread, but hopefully it will be mutually beneficial.

Following the posted steps and a little bit more, this is my current progress:

Phase 1 "Re-build Stock System"

1. Removed all the WD5000AAKB HDDs and set them aside for Phase 2!
2. Pulled two 1GB DIMMs from the system and reseated the last 1GB DIMM.
3. Found the stock drives stacked on a shelf
4. Set the stock WD1600BB HDDs to "single" by removing their jumpers.
5. Inserted one stock WD1600BB into bay 1
6. Started the system (Cold Boot)
7. Set the system to enter Recovery Mode on next boot. ("touch /nopivot")
8. Reboot (Warm Boot)
9. Preformed a fresh install of GOS 5.2.056
10. Reboot (Warm Boot)
11. Applied GOS 5.2.056 SP1 update
12. Reboot (Warm Boot)
13. Confirmed everything was in working order and checked the Event Log.
14. Shutdown the system
15. Performed Quick Erase with WD Data Lifeguard Diagnostic 5.04f on stock drives 2, 3, & 4.
16. Inserted the now "erased" stock drives 2, 3, & 4 into the system.
17. Started the system (Cold Boot)
18. Confirmed everything was in working order and checked the Event Log.
19. Created a new RAID 5 set and volume.
20. Resync time: 2 hours!
21. After resync, confirmed everything was in working order and checked the Event Log.
22. Removed the volume and RAID set
23. Reboot (Warm Boot)
24. Confirmed services which could be disabled are and the RAID set was removed.
25. Did a final check of the Event Log ... all seemed OK!
26. Shutdown the system.
27. Pulled and labeled stock drives 2, 3, & 4 and set them back on the shelf leaving stock drive 1 in bay 1 for Phase 3.

Phase 2 "Make it CLEAN!"

1. Performed Quick Erase with WD Data Lifeguard Diagnostic 5.04f on new drives 1, 2, 3, & 4.
2. Performing a Level 2 drive scan with SpinRite v6 on each drive (approx. 3 hours per drive). (CURRENT STEP)

Phase 3 "Build Upgraded System"

1. TBD

After the SpinRite process is over I let you guys know how the next phase works out (If I come back into work over the weekend ). If not it will most likely be Monday. Have a good weekend and thanks for the help!

[Phoenix32]

Originally Posted by Chewie

Removed all the WD5000AAKB HDDs and set them aside for Phase 2!

This is your problem. Change brands. No, I am not kidding.

[bitor]

Chewie, I hope it works. Keep the forum posted. The WD5000AAKB drives I have worked fine for me without any problems. In my opinion, the procedure from my notes that I posted are well known and have been contributed from multiple contributors in this open forum from multiple ppl. There is no one source that only one person has solely contributed to in the thoughts or ideals of this procedure from my post/notes of the escents/building of this procedure. It is a mixture of everybody that has contributed in this process. Either directly or indirectly, more or less.
Leave the egos, micromangent, my way or the high way, bulling tactics to this open forum at the door. This place is about learning and helping ppl. If you are looking for something other than that you will be disapointed. Help and expect nothing in return period.

bitor

[Phoenix32]

Chewie, just trust me on this. Change to another brand (or a much older revision WD drives) and your problem will disappear like magic.

Chewie and rmp.dmd1229, memory can be an issue during upgrades, esp with 5.x GOS revisions. 512MB minimum and 1GB+ far better. Not that this is your problem(s), just an extra note. When I wrote that procedure, I already knew the guy(s) using it had 512MB+ and 5.x had not become a thing yet. Thus why omitted from the original.

Originally Posted by bitor

The WD5000AAKB drives I have worked fine for me without any problems.

Bitor, are you really this stupid? This has been debated, researched, AND SOLVED, here on the forum. WD has changed the firmware in recent times on their NON RAID EDTION drives that causes major problems in RAID arrays. This is well documented all over the internet. SOME (read: few) will work, and used to work fine several years ago, including for myself in the past, but most will no longer work well in RAID arrays.

Originally Posted by bitor

In my opinion, the procedure from my notes that I posted are well known and have been contributed from multiple contributors in this open forum from multiple ppl.

Then as usual, your opinion is not worth much. I still have the original document I drafted up for an email helping someone and then also posted here to help people for this procedure. Funny, it is WORD FOR WORD the same as your posted procedure above.

I did not invent the procedure of how to install an OS on a Snap Server. My money would be on some engineer at Snap Appliance. BUT, the procedure in question here is the documentation you posted above, which I indeed did write.

--------------------

<Pissing contest removed>

---------------------

For others, sorry to interupt, I just can't help myself when it comes to bottom feeders like Bitor who live like a parasite on the backs of others. Sadly, he is one of the largest reasons I no longer come here beyond to read once a month or so. The work that has been done is still here for all of you to use, and truly hope it will help you solve your various problems. And, as many already have done, there is still email, LOL.

[bitor]

I stand by my statement and it is true and it is a FACT. Personal attacks from other members according to Dave the moderator are not allowed Phoenix32. Phoenix32 has personal attacked me on points that are false and not true.

Chewie, I hope it works. Keep the forum posted. The WD5000AAKB drives have worked fine for me without any problems.

In my opinion, the procedure from my notes that I posted are well known and have been contributed from multiple contributors in this open forum from multiple ppl. There is no one source that only one person has solely contributed to in the thoughts or ideals of this procedure from my post/notes of the escents/building of this procedure. It is a mixture of everybody that has contributed in this process. Either directly or indirectly, more or less.

Leave the egos, micromanagement, my way or the high way, bulling tactics to this open forum at the door. This place is about learning and helping ppl. If you are looking for something other than that you will be disappointed. Help and expect nothing in return period.

bitor

[Chewie]

I just couldn't let this wait until Monday ...

Phase 3 "Build Upgraded System"

1. Confirmed stock drive 1 is still in slot 1 and system is off
2. Set the new WD5000AAKB HDDs to "single" by removing their jumpers.
3. Inserted new drive 1 into slot 2
4. Started the system (Cold Boot)
5. Confirmed everything was in working order and checked the Event Log.
6. Confirmed the sync process has completed on the new drive in slot 2 via the Event Log.
7. Shutdown the system
8. Removed stock drive 1 from slot 1, label and allow it to join its comrades on the shelf
9. Removed new drive 1 from slot 2 and reinsert it into slot 1
10. Started the system (Cold Boot)
11. Set the system to enter Recovery Mode on next boot. ("touch /nopivot")
12. Reboot (Warm Boot)
13. Preformed a fresh install of GOS 5.2.056
14. Reboot (Warm Boot)
15. Applied GOS 5.2.056 SP1 update
16. Reboot (Warm Boot)
17. Confirmed everything was in working order and checked the Event Log, then cleared the log.
18. Shutdown the system
19. Insert the "cleaned" new drives from Phase 2 into slot 2, 3, & 4.
20. Started the system (Cold Boot)
21. *Drum-roll* .....
22. Phase FAILED

With two or more of the new drives in the system becomes sluggish plus the Event Log contains DMA timeouts and IDE bus resets. The initial GOS resync takes about 20 mins per drive, compared to the ~30 second resync with the stock drives. As long as I'm not transferring data to or from it, it works great ! haha

It seems others (via google) were successful using WD5000AAKB-00YSA0 (an earlier version) within other RAID enclosures, but were unable to get the later WD5000AAKB-00H8A0 versions to work.

I just happen to have the latter, so they will probably go back into their old FreeNAS enclosure where they had been working great as a tertiary backup for the last 1.5 years.

So what drives should I try? I've been able to find new Hitachi P7K500, Maxtor STM305004N1AAA, and Seagate ST3500630A OR I could roll the dice on some refurbished White Label drives. The Seagate ST3750640A are just to expensive for me to consider.

Most likely I'll use the stock drives until they fail, and put the system on a list for a rainy day mod project. I've been very pleased using Guardian OS for the last seven years and would like to continue using it at least for a little bit longer.

Once again, thank you for all your feedback.

[bitor]

Oh, sorry to hear that it failed and you are welcome for the help.
Well my drives in a raid are WD5000AAKB-00H8A0 model in a array and are working just fine with GOS. So, there you go. Some work some do not. But to be safe use a RAID Edition drive. Do your research yourself. I cannot stress that enough. Do not take just one person's advice on hard drives. Sounds like the timing is off. Try to turn off the Smart mode on the drives. That might help you. They have diff. time outs for non raid vs raid which is much shorter time. The command for turning off the smart error was posted on this forum before. I can look in my notes to see if I have it down and post if you like. If you are willing to try it again.

bitor

Originally Posted by Chewie

I just couldn't let this wait until Monday ...

Phase 3 "Build Upgraded System"

1. Confirmed stock drive 1 is still in slot 1 and system is off
2. Set the new WD5000AAKB HDDs to "single" by removing their jumpers.
3. Inserted new drive 1 into slot 2
4. Started the system (Cold Boot)
5. Confirmed everything was in working order and checked the Event Log.
6. Confirmed the sync process has completed on the new drive in slot 2 via the Event Log.
7. Shutdown the system
8. Removed stock drive 1 from slot 1, label and allow it to join its comrades on the shelf
9. Removed new drive 1 from slot 2 and reinsert it into slot 1
10. Started the system (Cold Boot)
11. Set the system to enter Recovery Mode on next boot. ("touch /nopivot")
12. Reboot (Warm Boot)
13. Preformed a fresh install of GOS 5.2.056
14. Reboot (Warm Boot)
15. Applied GOS 5.2.056 SP1 update
16. Reboot (Warm Boot)
17. Confirmed everything was in working order and checked the Event Log, then cleared the log.
18. Shutdown the system
19. Insert the "cleaned" new drives from Phase 2 into slot 2, 3, & 4.
20. Started the system (Cold Boot)
21. *Drum-roll* .....
22. Phase FAILED

With two or more of the new drives in the system becomes sluggish plus the Event Log contains DMA timeouts and IDE bus resets. The initial GOS resync takes about 20 mins per drive, compared to the ~30 second resync with the stock drives. As long as I'm not transferring data to or from it, it works great ! haha

It seems others (via google) were successful using WD5000AAKB-00YSA0 (an earlier version) within other RAID enclosures, but were unable to get the later WD5000AAKB-00H8A0 versions to work.

I just happen to have the latter, so they will probably go back into their old FreeNAS enclosure where they had been working great as a tertiary backup for the last 1.5 years.

So what drives should I try? I've been able to find new Hitachi P7K500, Maxtor STM305004N1AAA, and Seagate ST3500630A OR I could roll the dice on some refurbished White Label drives. The Seagate ST3750640A are just to expensive for me to consider.

Most likely I'll use the stock drives until they fail, and put the system on a list for a rainy day mod project. I've been very pleased using Guardian OS for the last seven years and would like to continue using it at least for a little bit longer.

Once again, thank you for all your feedback.

[willPower]

.

[Phoenix32]

Originally Posted by willPower

The Hitachi Deskstar drives are known to work quite well in GOS servers.

I would agree with willPower on this. I know a lot of people do not like Hitachi (calling them deathstar) drives, but I have never had any real problems with them myself.

I will add that Hitachi drives tend to use more power and thus generate more heat and run hotter (heat = bad in my book). This is due to them using an extra platter in many of their drives over their competitors. BUT! As I said, I have never had any real problems with them and they have a good track record in the GOS units as willPower said. So, I agree with willPower and IMO they are not a bad choice.

I myself prefer the Seagate drives (also more expensive) due to their longer warranty and excellent longevity of their PATA drives. I have had great success with their 500GB PATA drives in GOS units that have been worked very hard and for a long time (since 500GB drives hit the market).

I would not give you 2 cents for a Maxtor. I have had many very bad experiences with them over the years. But, some people swear by them.

Some people swear by Samsung, and I have recently been using a few of them, but I have not used them long enough to judge for myself. I can only relate what I have heard has been good.

I think in the end, it will be your preference and pocketbook that will have to decide. I hope this tid-bit of info helps.

[Chewie]

Very helpful information! I remember the deathstar days, but that was when they were IBM Deskstars and only 9GB.

If I'm going to spend the money, I would prefer to go with enterprise SATA drives. I have several ES and ES.2 I could use if I had an adapter.

I did order an inexpensive adapter last week using a Jmicron chipset, which "looked" like it could fit on the sled with minor modifications if any were even required. I won't have it until Wednesday.

willPower, I would be interested on the adapters you've had success with.