Pazi, taj backup koji ti imas ima smisla ako radis full restore do nekog point-in-time momenta - a onda evetualno radis replay binlogova.
Ako hoces da vratis samo neke podatke onda to mozes da prebacis u drugi database, pa da sql komanda prepakujes samo ono sto ti treba od podataka. Jos bolje resenje (po meni) je da radis svaku tabelu u odvojeni sql fajl (ili dva fajla, sql + txt za load data infile), ovo je ziva zgoda da vratis JEDAN slog koji ti fali.
Ne, ne mozes da zipujes sirov direktorijum, to ni na sta nece da lici. Mozes da radis hotcopy uz percona xtrabackup (odlican alat), ili uz komercijalni mysql backup. To je brzi restore za full bazu, ali manje selektivan. Dace ti isto sto sad imas, ali ce da radi mnogo brze i zapravo je bolje resenje, u smislu da zamenis ono sto sad imas. :)
Sve zavisi koji problem resavas, koliko ti je restore time kritican i koliko imas problema.... Realno, ja vise volim logicki backup, ali opet ja retko imam jedan db server, u nekoj semi sa bar 3 db servera i auto-failoverom, nikad nemas database downtime, pa ti backup najcesce vraca jedan slog ili nesto sto je ljudskom greskom izbrisano..... razlicit metod rada, razlicit prolem koji se resava.
P.S. Trojica pisemo u isto vreme :) - ali svodi se na use case, nemas "silver bullet". Ja npr. racunam da triggers i stored procedures imas u git-u/svn-u, pa ih ne bekapujem. Opet, ja backup radim da pokrijem human error, a ne catastrophic event (za to imam HA mehanizme), pa svesno imam projektovano dug restore u katastroficnom scenariju sa multiple hardware failiures.
Please do not feed the Trolls!
Blasphemy? How can I blaspheme? I'm a god!'