• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Raid Question

TheBuzzer

HACK THE WORLD!
Joined
Aug 15, 2005
Messages
13,028
Ok.
I am planning on building a new computer

in the general hard ware they said it was not good to do raid 0

now looking at the forum, ppl are doing raid 5.

is raid5 good? how is the speeds? is it faster than a single drive?

If so I think i will get like 4x320 gb hd for it
 
Raid 5 is generally slower than a single drive.. it is theoretically faster in reads, but is always slower in writes.. often much slower.
 
RAID 0 gives a small speed boost but I'd only run it if you keep backup religiously and don't mind having a 200% or higher chance of your hard drive going bad (since if 1 goes out you lose everything).

RAID 5 is a little slow but if a drive fails you just swap in a new one to replace it and build the array without any loss of data.
 
Dew said:
I highly recommend R5 as a STORAGE volume.


Here is a comparison of R0 versus R5 on a HighPoint RR2320 controller:


Formatting parameters: mkfs.xfs -f -b size=4k -d su=64k,sw=7 -i size=2k -l version=2 /dev/sda

Raid0, 3 drives
Code:
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Terabyte2       10G 57659  97 160824  35 67654  19 52272  90 213274  25 166.2   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 10040  68 +++++ +++  8756  57  9199  68 +++++ +++  3199  23
Terabyte2,10G,57659,97,160824,35,67654,19,52272,90,213274,25,166.2,0,16,10040,68,+++++,+++,8756,57,9199,68,+++++,+++,3199,23


Raid5, 6 drives
Code:
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Terabyte2       10G 52875  91 92245  22 60250  15 52540  90 253369  33 171.6   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  9890  83 +++++ +++  9307  71  8125  71 +++++ +++  1135   9
Terabyte2,10G,52875,91,92245,22,60250,15,52540,90,253369,33,171.6,0,16,9890,83,+++++,+++,9307,71,8125,71,+++++,+++,1135,9
 
is there an article explaining how to interpret that onslaught of numbers?
 
drizzt81 said:
is there an article explaining how to interpret that onslaught of numbers?

From the bonnie++ readme:
Bonnie++ Readme said:
# Test Details

* The file IO tests are:
1. Sequential Output
1. Per-Character. The file is written using the putc() stdio macro. The loop that does the writing should be small enough to fit into any reasonable I-cache. The CPU overhead here is that required to do the stdio code plus the OS file space allocation.
2. Block. The file is created using write(2). The CPU overhead should be just the OS file space allocation.
3. Rewrite. Each BUFSIZ of the file is read with read(2), dirtied, and rewritten with write(2), requiring an lseek(2). Since no space allocation is done, and the I/O is well-localized, this should test the effectiveness of the filesystem cache and the speed of data transfer.
2. Sequential Input
1. Per-Character. The file is read using the getc() stdio macro. Once again, the inner loop is small. This should exercise only stdio and sequential input.
2. Block. The file is read using read(2). This should be a very pure test of sequential input performance.
3. Random Seeks
This test runs SeekProcCount processes (default 3) in parallel, doing a total of 8000 lseek()s to locations in the file specified by random() in bsd systems, drand48() on sysV systems. In each case, the block is read with read(2). In 10% of cases, it is dirtied and written back with write(2).
The idea behind the SeekProcCount processes is to make sure there's always a seek queued up.
AXIOM: For any unix filesystem, the effective number of lseek(2) calls per second declines asymptotically to near 30, once the effect of caching is defeated.
One thing to note about this is that the number of disks in a RAID set increases the number of seeks. For read using RAID-1 (mirroring) will double the number of seeks. For write using RAID-0 will multiply the number of writes by the number of disks in the RAID-0 set (provided that enough seek processes exist).
The size of the file has a strong nonlinear effect on the results of this test. Many Unix systems that have the memory available will make aggressive efforts to cache the whole thing, and report random I/O rates in the thousands per second, which is ridiculous. As an extreme example, an IBM RISC 6000 with 64 Mb of memory reported 3,722 per second on a 50 Mb file. Some have argued that bypassing the cache is artificial since the cache is just doing what it's designed to. True, but in any application that requires rapid random access to file(s) significantly larger than main memory which is running on a system which is doing significant other work, the caches will inevitably max out. There is a hard limit hiding behind the cache which has been observed by the author to be of significant import in many situations - what we are trying to do here is measure that number.
* The file creation tests use file names with 7 digits numbers and a random number (from 0 to 12) of random alpha-numeric characters. For the sequential tests the random characters in the file name follow the number. For the random tests the random characters are first.
The sequential tests involve creating the files in numeric order, then stat()ing them in readdir() order (IE the order they are stored in the directory which is very likely to be the same order as which they were created), and deleting them in the same order.
For the random tests we create the files in an order that will appear random to the file system (the last 7 characters are in numeric order on the files). Then we stat() random files (NB this will return very good results on file systems with sorted directories because not every file will be stat()ed and the cache will be more effective). After that we delete all the files in random order.
If a maximum size greater than 0 is specified then when each file is created it will have a random amount of data written to it. Then when the file is stat()ed it's data will be read.


Basically, you want to look at Sequential Output(Block and rewrite), and Sequential Input(Block and seek).

The important numbers from my bechmarks:
R0, 3 drives
Sequential Read: 208MB/sec (213274KB/sec)
Sequential Write: 157MB/sec (160824KB/sec)
Seek time: 6ms (I THINK I'm interpreting the data correctly here)
R5, 6 drives
Sequential Read: 247MB/sec (253369KB/sec)
Sequential Write: 90MB/sec (92245KB/sec)
Seek time: 5.8ms (I THINK I'm interpreting the data correctly here)
 
Dew said:
Seek time: 6ms (I THINK I'm interpreting the data correctly here)
It says 166.2 seeks per second, or about .006 seconds per seek. Note, however, that that's with completely random I/O and a non-zero queue depth. In desktop-type apps this isn't a typical scenario.
 
So how does that translate to 20 people pulling files random files off the array?
 
Dew said:
From the bonnie++ readme:



Basically, you want to look at Sequential Output(Block and rewrite), and Sequential Input(Block and seek).

The important numbers from my bechmarks:
R0, 3 drives
Sequential Read: 208MB/sec (213274KB/sec)
Sequential Write: 157MB/sec (160824KB/sec)
Seek time: 6ms (I THINK I'm interpreting the data correctly here)
R5, 6 drives
Sequential Read: 247MB/sec (253369KB/sec)
Sequential Write: 90MB/sec (92245KB/sec)
Seek time: 5.8ms (I THINK I'm interpreting the data correctly here)

Also of note, the number of drives will affect performance.. so comparing 3 drives to 6 drives is comparing apples to oranges.
 
Lazn_Work said:
Also of note, the number of drives will affect performance.. so comparing 3 drives to 6 drives is comparing apples to oranges.

Here is 6 drives, R0:
Code:
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Terabyte2       10G 57447  96 230452  51 92955  34 53085  90 271680  33 172.1   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 11173  75 +++++ +++ 11125  71  1972  14 +++++ +++  7359  54
Terabyte2,10G,57447,96,230452,51,92955,34,53085,90,271680,33,172.1,0,16,11173,75,+++++,+++,11125,71,1972,14,+++++,+++,7359,54
 
Dew said:
So how does that translate to 20 people pulling files random files off the array?
Not very well. I've written a tool that simulates (poorly) many users reading data as fast as possible off a block device, but it's not very good - it doesn't report aggregate rates, just individual processes reporting how fast they're going, there's no provision for preventing thread starvation, etc.

In general, if your filesystem is defragged, you can assume transfer rate of N high-bandwidth sequential transfers is pretty close to one. So 250 MB/s off 6 drives in raid 5 should be about right. However, that assumes good request behavior from the application and good network to send the data over. I don't know what that translates to in the real world, though.
 
Dew said:
So how does that translate to 20 people pulling files random files off the array?

On a single network card setup you'll be network bound with those disk benches, even with gigE.
 
longblock454 said:
On a single network card setup you'll be network bound with those disk benches, even with gigE.

I wish. I'm not sure what the actual issue is, but when I have 40 concurrent transfers (20 each, to two different machines), I max out at 40MB/sec. But if I start 40 copies of the same 800MB file (so it pulls from the RAM cache linux makes) it transfers at 113MB/sec.

Here are the numbers(start copy file NUL):
NOTE: I have a rotating set of 45 800MB files, to make sure I completely bypass the caching. Numbers are +/- 5MB/sec since that is how much they can vary from run to run.
1 = 62MB/sec
2 = 113MB/sec
3 = 113MB/sec
4 = 93MB/sec
5 = 89MB/sec
6 = 88MB/sec
7 = 85MB/sec
8 = 93MB/sec
9 = 77MB/sec
10 = 88MB/sec
23 = 44MB/sec
45 = 48MB/sec
 
so. what your saying raiding isnt really that fast?

how much speed increase does raid 0 have compared to a single drive

or how much speed increase does raid 5 with 4 drives compare to a single drive?
 
TheBuzzer said:
so. what your saying raiding isnt really that fast?

how much speed increase does raid 0 have compared to a single drive

or how much speed increase does raid 5 with 4 drives compare to a single drive?


Oh, it IS fast. I'll do some benchmarks of single, versus R0 with 2 drives, versus R0 with 4 drives, versus R5 with 4 drives.
 
Single:
Code:
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Terabyte2       10G 56653  95 60925  13 29660   6 51104  86 77161   8 137.1   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  4486  29 +++++ +++  3628  20  4018  28 +++++ +++  1077   7
Terabyte2,10G,56653,95,60925,13,29660,6,51104,86,77161,8,137.1,0,16,4486,29,+++++,+++,3628,20,4018,28,+++++,+++,1077,7

Read: 75MB/sec
Write: 59MB/sec

R0, 2 Drives:
Code:
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Terabyte2       10G 57439  97 114960  25 48172  13 51425  88 148996  17 156.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  8232  56 +++++ +++  6596  40  7154  53 +++++ +++  2329  16
Terabyte2,10G,57439,97,114960,25,48172,13,51425,88,148996,17,156.5,0,16,8232,56,+++++,+++,6596,40,7154,53,+++++,+++,2329,16
Read: 145MB/sec
Write: 112MB/sec


R0, 4 Drives:
Code:
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Terabyte2       10G 57473  97 164002  36 74720  23 52741  90 250197  29 169.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 11101  75 +++++ +++  9678  64  9844  71 +++++ +++  4106  28
Terabyte2,10G,57473,97,164002,36,74720,23,52741,90,250197,29,169.8,0,16,11101,75,+++++,+++,9678,64,9844,71,+++++,+++,4106,28
Read: 244MB/sec
Write: 160MB/sec



R5, 4 Drives:
Code:
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Terabyte2       10G 54189  93 79865  21 46580  11 51985  89 204319  26 162.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  8128  68 +++++ +++  7645  60  7780  67 +++++ +++   820   6
Terabyte2,10G,54189,93,79865,21,46580,11,51985,89,204319,26,162.5,0,16,8128,68,+++++,+++,7645,60,7780,67,+++++,+++,820,6
Read: 199MB/sec
Write: 78MB/sec


R50, 6 Drives:
Code:
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Terabyte2       10G 53988  93 95249  23 53741  14 52061  89 241276  32 170.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  9599  69 +++++ +++  8196  64  8841  73 +++++ +++  1386  11
Terabyte2,10G,53988,93,95249,23,53741,14,52061,89,241276,32,170.5,0,16,9599,69,+++++,+++,8196,64,8841,73,+++++,+++,1386,11
Read: 235MB/sec
Write: 93MB/sec
 
Dew said:
I wish. I'm not sure what the actual issue is, but when I have 40 concurrent transfers (20 each, to two different machines), I max out at 40MB/sec. But if I start 40 copies of the same 800MB file (so it pulls from the RAM cache linux makes) it transfers at 113MB/sec.

Here are the numbers(start copy file NUL):
NOTE: I have a rotating set of 45 800MB files, to make sure I completely bypass the caching. Numbers are +/- 5MB/sec since that is how much they can vary from run to run.
1 = 62MB/sec
2 = 113MB/sec
3 = 113MB/sec
4 = 93MB/sec
5 = 89MB/sec
6 = 88MB/sec
7 = 85MB/sec
8 = 93MB/sec
9 = 77MB/sec
10 = 88MB/sec
23 = 44MB/sec
45 = 48MB/sec

Read up on OLTP (online transaction processing) effects on disk/network performance, same basic principle/effect your seeing with concurrent users. It becomes IO bound, most likely network, but possible disk as well.
 
TheBuzzer said:
cool. thx.

so i think i am going to get raid 5 config than.
Sequential reads and writes aren't everything. Bonnie++ does a good job of showing what your disk will behave like if you read or write to large files in order, but not a great job of showing what it will do while booting Windows or loading a game level.

Use raid 5 for bulk storage, and get a Raptor for a boot drive if fast is what you want. And buy a hardware raid card like an Areca; doing the raid calculations in software works fine, but if you're going for ultimate speed you need dedicated hardware.

 
Raptor drives cost too much for space amount.

the motherboard i am getting is: i think it supports raid 5 already
http://www.newegg.com/product/produ...N82E16813188009

Fancy meeting you here ;p

I guess, what I don't understand is why you're so against the Raptor. It is going to be the best drive for an OS/Game drive because of it's speed. We're not saying get 5 Raptors and RAID5 them together. If you want storage and speed then....

RAID 5 - Storage (Whatever size drives you want)
&
Raptor - OS/Games

And, the thing about RAID5 is that it's pretty CPU intensive, any RAID5 on a motherboard is software from my understanding.

The CPU will have to do the parity calculations which it's not very effecient at.

If you want to do RAID5 right, take one of the PCI-E x 16 Slots and throw this in

Wikipedia FTW: http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks
 
but does hd really have a big impact of game speed (FPS) or just the loading times?

also vista is suppose to have a usb key to do a faster boot.


so the raid 5 on motherboard is software. the qx6700 should be able to do it without slowing down the computer. if quad core can't do raid 5 fast in software that is sad :)
 
TheBuzzer said:
but does hd really have a big impact of game speed (FPS) or just the loading times?
Just loading times, generally. Some games do load things in the middle of a level, though, to prepare for entering a new area (Halo did this, for example).
TheBuzzer said:
so the raid 5 on motherboard is software. the qx6700 should be able to do it without slowing down the computer. if quad core can't do raid 5 fast in software that is sad :)
The problem with motherboard raid is it's done as cheaply as possible. Thus, with poorly written software, you could easily drag down the whole system. Sad it is, but bad software will slow you down.
 
TheBuzzer said:
so. what your saying raiding isnt really that fast?
No, I think what everybody here wants to say is that RAID-N, where N is a RAID-level, is not a one-size-fits-all solution. There are pro's and con's to weigh. Sometimes, RAID-0 is the "most appropriate" solution, sometimes it it not. For example: If you were working with something that was bound by sequential transfer rate, RAID-0 is going to improve your experience. If you are working with something that is seek rate bound, RAID-1 may help you out a bit. If you are looking for an uptime solution of data that is mostly read, RAID-5 may be a good choice.

The bottom line is that statements like such as "in the general hard ware they said it was not good to do raid 0" are blanket statements and should not be applied to this topic.

To answer your questions:
"is raid5 good?" - Yes and No
"is it faster than a single drive?" - Yes and No

You have said nothing about your intended application, which leads me to believe (yeah I am naive) that you are planning to put your operating system on it, which made me state that RAID-5 is usually not a good choice for an OS volume, since usually people have swap files on their OS volume and usually software based RAID-5 does not handle random writes well.

I would recommend that you read up on RAID levels and their benefits and drawbacks:
http://www.storagereview.com/guide2000/ref/hdd/perf/raid/levels/index.html

There are at lot of similar articles, if you prefer get a second opinion.

An alternative would be to tell us what your intended application is. At that point, we can start flaming each other again about whether RAID-0 is a good or poor choice for a gaming rig....
 
well i want 4 internal drives max

2 of them will be connected to a port in the back to make them esata.

already got a hd in a case that support esata.


so it seems like games like halo load in middle and stuff. but still is that worth it.

donno. i am starting to see doing raid isnt even worth it based on in order to have a good raid you got to get rapitor drives.
 
TheBuzzer said:
but does hd really have a big impact of game speed (FPS)
If your HDD is impacting your FPS, I suggest that you look at adding more system and/or video memory to your computer.
 
donno. i am starting to see doing raid isnt even worth it based on in order to have a good raid you got to get rapitor drives.

That's not quite true. Raptor drives are the fastest consumer-level drives out there, so for pure speed, doing any RAID with Raptors will be faster.
 
TigerDirect has that chip for $300 less. Just a heads-up.

My recommendation for a hard drive subsystem for that machine is a single ADFD raptor (the 150 has MIR putting it at $195 right now) and as many 7200.10 or T7K500 drives as you want to get the storage capacity you want, in raid 5. If they're just for media, it doesn't matter that they won't be terribly fast at random I/O stuff. The Raptor will most likely be faster than any raid 5 setup that's within an order of magnitude of price. That's why they're expensive.
 
in the general hard ware they said it was not good to do raid 0

LOL. All raid setups are bad for certain situations. Its not always never bad to do raid0 (yea, go read that again :) )

I have a 500Gb raid0 with a 48Gb raid1 for backups. Its very very quick, and I have integrated backups, all across 2 drives. Although I do want a 3rd drive now for more speed.

RAID5 has its place. But it makes NO sense for me at all.
 
este said:
Its very very quick, and I have integrated backups, all across 2 drives.
Please stop saying this. You do not have integrated backups - if you accidentally delete a file from your raid 1 array (or the cheap integrated controller gets configuration problems) it's gone forever. Backups are offline, read-only, and preferrably permanently stored. Your raid 1 array isn't a backup, and saying it is won't make it so.
 
unhappy_mage said:
Please stop saying this. You do not have integrated backups - if you accidentally delete a file from your raid 1 array (or the cheap integrated controller gets configuration problems) it's gone forever. Backups are offline, read-only, and preferrably permanently stored. Your raid 1 array isn't a backup, and saying it is won't make it so.

Agreed, RAID is NOT a backup. It can greatly decrease chances of data loss, but it is not a backup. For my setup, only root has write access to my array. I have to manually(well scripted) move files from the upload folder on the system drive. This greatly decreases the risk of a virus on the windows side having ANY impact on my data.
 
I'm not sure how you'd even gauge reliability on a matrix raid setup like that.
The system shares the same points of failure in some ways, and in others not.

How do you deal with disk failure in that kind of setup, or even loss of settings from flashing the BIOS?
I've only ever used standard Adaptec SCSI RAID5 controllers and Promise IDE/SATAs for RAID1 (before unhappy recommended that highpoint to me.)
If a disk fails in an intel matrix setup like that, can you even put the drive in another computer and have it recognize the RAID1 portion of the drive? I want to say partition, but it's not, it has to be more of a lower level form of organization for it to be done at the controller level.
 
unhappy_mage said:
Please stop saying this. You do not have integrated backups - if you accidentally delete a file from your raid 1 array (or the cheap integrated controller gets configuration problems) it's gone forever. Backups are offline, read-only, and preferrably permanently stored. Your raid 1 array isn't a backup, and saying it is won't make it so.

If I delete something from my RAID-1 there better be a good reason for doing so. Its all marked read-only so there is a prompt, THEN there is a recycle bin, and THEN if for instance I wake up completely retarded and still manage to delete my important files, there is undelete, after that I wouldn't even really care b/c they aren't THAT important.

Like it or not I have 2 physical copies of all my important files. No burning discs, no uploading , no tapes, no external hdd, no inconvenience. Its integrated into my system.

I have no use for offline, read-only, or permanently stored backups, for FOR ME - 2 physical copies IS a backup. Thats WAY more then the 95% of people out there that are using 1 hdd drive.

I still make a very infrequent true backup and throw it in the bank. In case of fire or some bs. But, considering how many times my system has been stolen and burned (zero times). Its not an issue. So I'd rather enjoy the speed of my system then worrying about everything that 'could' happen.


I certainly would not be some presumptuous to tell someone their system is not good enough for them.
 
este said:
*snipped excuses*

I certainly would not be some presumptuous to tell someone their system is not good enough for them.

A copy onto another hard drive in the same system is not a backup, it is a copy. One good power spike and boom, we all laugh. Please stop trying to misinform the lesser noobs with your poor technique.
 
Back
Top