Member Avatar for Rudy Jaef

while taking the backup my system used to closed the terminal and show's me the folder on usbdisk where i have copied my all data when my the process of copying is completed but from last week it never shows me the folder and terminal remains open as it is coping is continew but its actullay done i have to close the terminal my self and check my self while measuring the the size of the usb disk folder and folder and size of the folder on my system. how could i get those settings back to let me know automatically so i dont have to guess and close while its processing. i use cp -rf /proddb/ /media/usbdisk/prod_bkupsep13/proddb. this command to copy the proddb data. please help

  • 2 Contributors
  • 4 Replies
  • 303 Views
  • 5 Days Discussion Span
  • Latest Post Latest Post by rubberman

Dani AI

Generated

Quick diagnosis and practical fixes for the symptom described (copy appears to finish but the terminal stays open and the folder no longer pops up): this is usually one of three things — the terminal emulator/profile behavior changed, the copy was previously run via a wrapper that opened the file manager when done, or the copy is finishing at the user-space level while kernel write caches are still flushing to the USB. is right to push for detached runs and checksums; below are simple checks and safe workflows you can apply immediately.

Checklist to diagnose (run from the same terminal session):

jobs -l
ps -ef | less
sudo lsof /path/to/usb      # shows processes still holding files on the USB
mount | grep /path/to/usb   # check mount options (look for 'sync' vs 'async')

If the copy process is gone but writes still seem to be happening, run sync to force kernel buffers to disk. Also check your terminal profile preferences (some terminals have “When command exits: Hold/Close” options) — that explains the earlier automatic close.

Reliable unattended-copy workflow

# inside a screen/tmux session, or with nohup/disown:
nohup rsync -a --info=progress2 /path/to/source/ /path/to/usb/backup/ > ~/backup.log 2>&1 &
disown
sync
xdg-open /path/to/usb/backup &

Using rsync gives restartability and clearer progress; running it in screen/tmux or with nohup prevents the copy being killed if you close the terminal. The final sync ensures data is flushed; xdg-open will show the folder in your desktop file manager.

Verify integrity (simple, robust)

find /path/to/source -type f -print0 | xargs -0 sha256sum | sort -k2 > /tmp/src.sha256
find /path/to/usb/backup -type f -print0 | xargs -0 sha256sum | sort -k2 > /tmp/dst.sha256
diff /tmp/src.sha256 /tmp/dst.sha256

If diff is empty, files match. Finally, always unmount/eject the USB before physically removing it. This combination (rsync + screen/nohup + sync + checksum) will restore predictable behavior and protect your backups.

Recommended Answers

All 4 Replies

Member Avatar for Rudy Jaef

i am using linux as operating system. server sepecificatio is system x3650 IBM runing oracle 11i on it.

Member Avatar for rubberman

So, you say it copies the data correctly (you have verified that with cksum or md5sum, right?), but just doesn't close the terminal window when done? There can be many reasons for that, including unintended input in the terminal window, so our being able to determine exactly what is causing this symptom is pretty difficult to accomplish... :-(

Member Avatar for Rudy Jaef

yes it copies correctly but doesn't close the terminal window when done.. is there any setting of OS or i am making any mistake. i check the size by du -sh /proddb/ then compare it to the folder i copied on usbdisk.

Member Avatar for rubberman

Running a checksum calculation on the data is the only sure way to be sure that the copy was successful. Size alone is not definitive.

As for your process of running this in an open terminal is concerned, that is not the best approach to use. I would run it detached with nohup and redirect stdout and stderr to specific files. If you run it as a shell script, then after the transfer you can compare checksums of the source and destination files to validate the transfer, writing the results (success or failure) to stderr (the specified file) which you can review later. You could also email that info to you or a mail list as well.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.