Why Not Compress Backups?

Sure there is a very important reason for that. If you use compression you use more time. If you have a 1TB SQL Database that say takes you 16 hours to do a full backup without compression might take you (fake number) 22 hours using compression. This in turn would not be as wild but consider if you have to restore a compressed backup, it will take longer as well and espcecially on DB's (depending on the make), the DB would be down for that time and you want to limit the downtime to as little as possible.

Your drives top speed is going to be constrained by mechanical components. The I/O involved will probably be several hundred times slower than the electron speeds used to compress and transmit.

Compressed files may have a faster transmission rate than ucompressed ones depending upon the devices at each end. Most modern network devices compress and uncompress through the firmware when sending/recieving network traffic. Some of them are smart enough to realize that the data is already compressed and will skip that step on each end.

Also, dedicated backup networks don't usually use tcp/ip. Other protocols are much faster and deal with larger packet sizes and different erro algorithms. Many of those networks are optimized for compressed files.


Edited by dpyers - 22 October 2005 at 4:16pm

the boss wrote: well whaaaat protocol other can TCP/IP can be used??? may i ask

Actually, the protocol is just the IP part of TCP/IP

Other common protocols are IPX/SPX, ATM, Frame Relay, SNA, OSI, AppleTalk, DSI, about a dozen or two that end in COM - e.g. TCOM, NDISCOM, etc., and a bunch that start with Data - e.g. Datakit, DataLinks, etc. Just about every high end router manufacturer also has proprietary protocols, and there's a whole slew of them for fiber and other high speed connections - T3+/OC, etc.

There's probably a few hundred communications protocols floating around. TCP over IP was designed for reliability, not for speed. One of it's major characterisitc is the small size of it's data packets coupled to relatively large header and trailer info that eable each packet to "self route" over possible widlely divergent paths and get then have the packets get reassembled in the proper order regardless of the sequence they come in. Error checking the sequence for packets it is expecting but haven;t arrived yet, and asking for retransmission can cause 10-40% wasteage of the of packets that just weren't designed for speed to begin with.

Each comminication protocol is designed for a specific set of requirements. Backup protocols often only have header and trailer info every 100 or every 1000 packets as they usually lock the path the transmission takes. A packet can also be hudreds of time larger that an IP packet. They also typically have additional channels for crc info and packet admin so the actual data is more of a pure stream instead of a series of packets.




Edited by dpyers - 23 October 2005 at 10:07am

Hey... if you can't dazzle them with brilliance... baffle them with bullsh*t