The size of the parent file doesn�t increase beyond 2000000 !!!!!
I am not able to understand that why the size of the files after gzip keeps on increasing when the size of the parent file doesn�t increase beyond 2000000 !!!!
When I delete the older logs the gzip again starts behaving in the same fashion i.e the 1st file of less size and gradually the size of files increases like the above one .
I am very surprised by this behavior !
Could anyone please help me to understand the problem or is there something wrong with my logic or way of doing it !!!!
Is there any other command similar to tar and gzip ??
Why are you surprised? You are archiving all the same logs over and over. Naturally your archives get bigger over time, the later files hold all the old files plus newer ones.
After executing it. All the list of the backup log files were displayed. The size of the file doesn't got reduced. Like before it is again doing the tar and gzip operation on the already done files and because of that the size of the backup file is increasing !!!
---------- Post updated at 01:08 PM ---------- Previous update was at 12:39 PM ----------
Hi,
Please let me explain my requirement and the bottleneck!
My Requirement:-
In our main file BLUESTAR_Archieve.log the logs gets appended every day.
So, we are required to take the back-up of the log files daily based on timestamp.
For this I have written a script :-
After getting the post from fellow members. I came to realize that the tar and gzip are performing the action on the files on which this action had already been performed.
I tried the below command also :-
Tar �tvf <tar_file >
But this is displaying all the files in the BackupLogs !!!
Is there any way around. So, that the tar and gzip don�t perform the same operations on the already performed files.
I don't need the tar and gzip to perform the same action on the already done files. Instead it should be doing the tar and gzip action only on new files !
Please suggest/ help !
The latest script posted is contains typing errors (not just the spelling of Archive). There is an extra space character in the destination of the mv command /app/local/XXX/XXX/XXX/logs /LogsBackup which could be a disaster.
There are two extra spaces in: rm �f /app/local/XXX/XXX/XXX/logs / BLUESTAR_Archieve.log _$(date +%y_%m_%d_%H_%M)
which will give rm three separate arguments.
Anyway the process seems to contain the same design problem:
/app/local/XXX/XXX/XXX/logs/LogsBackup
is a subdirectory of:
/app/local/XXX/XXX/XXX/logs
so your tar will pick up the lot.
Now if your directory structure was like this, you would not have the problem:
Do understand this command? Ignoring the typing errors (extra space after .log) and the spelling of Archive.
It would take the entire contents of the directory tree /app/local/XXX/XXX/XXX/logs and archive it into an archive file called BLUESTAR_Archieve.log _$(date +%y_%m_%d_%H_%M).tar .
The command as stated does not create a tar archive of the single file called BLUESTAR_Archieve.log _$(date +%y_%m_%d_%H_%M) .
Also, evaluation the current time in every command is not a good idea. One day your script will overlap a change of minute.
I think that we need to know what the script is meant to do. If there is only one log, the tar is pointless.