Skip to Content

Fast Copy of Filesystem With Tar

Small tips matter a lot !

We had a situation where 2 TB of database (data files) needed to be copied between filesystems.


Traditional linux cp command used to take 7 hours, even when multiple cp processes were fired in background with nohup.


Necessity forced me to explore and I hit two links.—Linux!.aspx



I am supposed to copy /oracle/S1Q/sapdata1…..sapdata10 to  /oracle/S1X/sapdata1…..sapdata10

They are both located on the same host.


Logged in as oras1x (owner of S1X database)

     cd /oracle/S1Q

     nohup tar -Sc sapdata1/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata2/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata3/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata4/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata5/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata6/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata7/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata8/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata9/ | tar -C /oracle/S1X / -xv &

     nohup tar -Sc sapdata10/ | tar -C /oracle/S1X / -xv &


Monitored the copy speed every 60 seconds.

The average speed was 12.6 GB per minute.

The peak speed it touched once was 56.57 GB per minute.

The lowest speed was 5.86 GB per minute.


The copy was completed in 3 hours.


Below is the graph :-



Hope this helps someone with similar requirement.


Good Luck !

You must be Logged on to comment or reply to a post.
  • Thanks for sharing this handy way for handling copies of larger files.

    There are some issues with this nevertheless.
    The database you copy the files from needs to be either shutdown or the datafiles need to be in online backup mode. If this isn’t the case, the target files are just crap.
    Also, you don’t have a block check for the copied files. And with literally millions of blocks to be copied, you definitively want to have such a check.

    Thus, for Oracle datafiles a much better option is to use the RMAN clone/copy features. These are also integrated into the BRTOOLS and no command line typing is required.
    On top of that, the BRTOOLS system copy takes care on all the other little details around such an action.
    for details on this.

    With this you get everything: logging, start/stop/resume copy actions, parallelisation…
    And that even while the source database is fully up and running!

    Best regards,

    • My article is limited to only using tar to perform fast filesystem copy, and not covering methods to perform DB copies.

      Yes, there are several methods of performing DB copies. For example, split mirror based, SAN bad, etc can be much faster than BRTOOLS based, RMAN based.

      If anyone has any facts, data, statistics, graphs etc please reply adding the same.

      • Sure and the limitations are accepted.
        But not using the BRTOOLS is one of the major causes for serious operation problems in SAP systems.
        There is so much to do wrong when working on the bare OS shell level.
        The BRTOOLS and RMAN come together with SAP/Oracle and don’t cause any additional costs – so using them where possible really is a very good and professional idea.

        BTW: OS level tools like tar, cp, dd, cpio usually work with rather small IO blocking and don’t use FS features like DirectIO or ConcurrentIO. RMAN uses all the features that the DB instance itself uses.
        With that better IO performance can be achieved even without expensive storage systems that offer snapshot-copies.