New answers tagged tar
for i in $(tar -tzf foo.tar);do ls -d ~/$i 2>/dev/null;done
Solved the issue. Couple things at fault here: The script creates the blob with a filename starting with $distro, which happens to begin the filename with a #, which is a reserved URI character. I changed the script so that it resembled $type_$date instead. The storage blob command was failing (silently) because the script wasn't running them with sudo ...
Blob names require you to escape reserved URL characters. Your blob name starts with a # which is a reserved URL character. I suspect the issue will resolve itself when you remove that character (or escape it). Note: I haven't confirmed this with an independent test, but it's the first time I've ever seen a blob name with a # character... More info on blob ...
Let's assume that you tarred /etc directory and now you want to compare the tar filelist against the live filesystem. You can use the following commands to generate the filelist, and the diff the two list. To generate the live filesystem list: find /etc | cut -c 2- | sort > fs.list To list the files inside tar: tar -tf etc.tar.gz | sed 's//$//' | sort > ...
If you want to do this with tar and not rsync, you can paralelize your tasks : source : tar ... | nc host port destination : nc -l -p port | tar ... It will at least reduce your time by two
I would stick to relative paths: tar -czvf product.tar.gz --exclude="product/cache" product/ (it works for me).
rsync will copy only diffs - only changes from source to target server. If you already have copy of your data on new server, rsync will only copy what has been changed between your tar and actual state.
Rsync may allow you to sync the files without taking the server down. For example, you could do a sync while in production, then take the server down, sync again to make sure you got everything that changed in the mean time, and then turn on the new server. The second sync will be incremental, and would take a fraction of the time of the whole, minimizing ...
You will have to test to find out. There are many variables such as the speed of your storage system. Consider restoring your tar archive or backup while the old system is up. Then during the downtime use rsync to copy the remaining changes. It still has to check many file modify times which takes time, but there is much less I/O and network transfer. This ...
Top 50 recent answers are included