Why Not Compress Backups?
Printed From: Web Wiz Forums
Category: General Discussion
Forum Name: General Discussion
Forum Description: General discussion and chat on any topic.
URL: https://forums.webwiz.net/forum_posts.asp?TID=16971
Printed Date: 30 March 2026 at 11:40pm
Software Version: Web Wiz Forums 12.08 - https://www.webwizforums.com
Topic: Why Not Compress Backups?
Posted By: davidshq
Subject: Why Not Compress Backups?
Date Posted: 20 October 2005 at 4:39pm
|
Backup compressions decreases the size of the files and speeds up
transfer, so why would one choose not to use compression on a
backup? Is there any reason? I am implementing a Veritas Backup Exec
solution and see that one can choose not to use compression, or use
only hardware or software compression. Is there any reason I wouldn't
want to use compression or why I wouldn't want to use both hardware and
software compression? David. ------------- - http://www.davemackey.net/" rel="nofollow - Dave Mackey - Virtual Home. |
Replies:
Posted By: michael
Date Posted: 20 October 2005 at 6:06pm
|
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.
There may be other reasons as well but I see that as the main one. ------------- http://baumannphoto.com" rel="nofollow - Blog | http://mpgtracker.com" rel="nofollow - MPG Tracker |
Posted By: davidshq
Date Posted: 22 October 2005 at 12:19pm
|
Michael, Thanks for the thoughts. The interesting thing with compressing backups on my device (a PowerVault 132T) is that it transfers at a much faster rate when the data is compressed than when it is uncompressed. So the job actually goes faster? We have to do our backups over a backup network so we don't interfere with other network traffic, and even at gigabit rates this cause a slow-down in backup speed...I'm wondering perhaps if the drive is fast enough that it can compress the files and still send them at the best rate the network can handle. David. ------------- - http://www.davemackey.net/" rel="nofollow - Dave Mackey - Virtual Home. |
Posted By: dpyers
Date Posted: 22 October 2005 at 4:10pm
|
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. ------------- 
Lead me not into temptation... I know the short cut, follow me. |
Posted By: the boss
Date Posted: 23 October 2005 at 7:49am
|
well whaaaat protocol other can TCP/IP can be used??? may i ask ------------- http://www.web2messenger.com/theboss"> 
|
Posted By: dpyers
Date Posted: 23 October 2005 at 10:04am
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. -------------
Lead me not into temptation... I know the short cut, follow me. |
the boss wrote:Posted By: the boss
Date Posted: 24 October 2005 at 3:21pm
i did not ask for a lesson in protocols... i just asked what are preffered protocols for data backup networkd!!  ------------- http://www.web2messenger.com/theboss">
|
Posted By: dpyers
Date Posted: 24 October 2005 at 6:39pm
Hey... if you can't dazzle them with brilliance... baffle them with bullsh*t 
-------------
Lead me not into temptation... I know the short cut, follow me. |
Posted By: davidshq
Date Posted: 25 October 2005 at 11:12pm
|
Thanks for the thoughts. I have decided to go with compressing the
backups...But I am also leaning towards attempting to find a better
technology eventually. This whole backup-to-disk thing looks
interesting. Especially the drives that work inside of tape drives (so
you don't loose your investment). Tape just seems too slow for large
amounts of data. David. ------------- - http://www.davemackey.net/" rel="nofollow - Dave Mackey - Virtual Home. |