find . | cpio -vpdm ~+1
find . | cpio -vpdm ~+1
Duplicate volume:
find . -xdev -depth -print | cpio -apdm ~+1 !! 2>&1 | grep -v 'newer or same age'
-v, --verbose
List the files processed, or with -t, give an `ls -l' style ta-
ble of contents listing. In a verbose table of contents of a
ustar archive, user and group names in the archive that do not
exist on the local system are replaced by the names that corre-
spond locally to the numeric UID and GID stored in the archive.
-V --dot
Print a "." for each file processed.
In copy-out mode, cpio copies files into an archive. It reads a list of filenames, one per line, on the standard input, and writes the archive onto the standard output.
In copy-in mode, cpio copies files out of an archive or lists the archive contents. It reads the archive from the standard input. Any non-option command line arguments are shell globbing patterns; only files in the archive whose names match one or more of those patterns are copied from the archive. Unlike in the shell, an initial '.' in a filename does match a wildcard at the start of a pattern, and a '/' in a filename can match wildcards. If no patterns are given, all files are extracted.
In copy-pass mode, cpio copies files from one directory tree to another, combining the copy-out and copy-in steps without actually using an archive. It reads the list of files to copy from the stan- dard input; the directory into which it will copy them is given as a non-option argument.
-0, --null
In copy-out and copy-pass modes, read a list of filenames ter-
minated by a null character instead of a newline, so that
files whose names contain newlines can be archived. GNU find
is one way to produce a list of null-terminated filenames.
-a, --reset-access-time
Reset the access times of files after reading them, so that it
does not look like they have just been read.
-A, --append
Append to an existing archive. Only works in copy-out mode.
The archive must be a disk file specified with the -O or -F
(--file) option.
-c Identical to "-H newc", use the new (SVR4) portable format.
-d, --make-directories
Create leading directories where needed.
-E FILE, --pattern-file=FILE
In copy-in mode, read additional patterns specifying filenames
to extract or list from FILE. The lines of FILE are treated
as if they had been non-option arguments to cpio.
-i, --extract
Run in copy-in mode.
-l, --link
Link files instead of copying them, when possible.
-L, --dereference
Dereference symbolic links (copy the files that they point to
instead of copying the links).
-m, --preserve-modification-time
Retain previous file modification times when creating files.
--no-absolute-filenames
In copy-in mode, create all files relative to the current
directory, even if they have an absolute file name in the
archive.
-o, --create
Run in copy-out mode.
-p, --pass-through
Run in copy-pass mode.
-v, --verbose
List the files processed, or with -t, give an `ls -l' style
table of contents listing.
-V --dot
Print a "." for each file processed.
[filename generator] | afio -o [options] archive : write archive
afio -i [options] archive : install archive
afio -t [options] archive : list table-of-contents of archive
afio -r [options] archive : verify archive against filesystem
Frequently used options:
General: -v : verbose
-Z : with -o: gzip files when writing them to the archive,
with -i/t/r: handle archive written with -Z option
-5 : abort instead of creating archive incompatible with cpio
Install: -n : protect newer files -k : skip corrupt data at beginning
Select: -y [pattern] : only process files matching pattern
-Y [pattern] : do not process files matching pattern
-h Follow symbolic links, treating them as ordinary files and
directories.
afio is a better way of dealing with cpio-format archives. It is generally faster than cpio, provides more diverse magnetic tape options and deals somewhat gracefully with input data corruption. It supports multivolume archives during interactive operation. afio can make compressed archives that are much safer than compressed tar or cpio archives. afio is best used as an "archive engine" in a backup script.
$ find . -depth -print0 | afio -px -0a new-dir
All my backups onto tape use afio.
http://www.linuxgazette.com/node/8447
The nice thing about using afio with the compression option is that because of the way that afio stores its archives, if one of the files becomes corrupted — hey, it can happen to anyone — it doesn't prevent you from retrieving the remainder of the intact files. If you tar and gzip an archive and it has an error, you're out of luck, pal. It's history. The whole thing.
Create an archive with compressed files: find .... | afio -o -v -Z /dev/fd0H1440
Install (unpack) an archive with compressed files: afio -i -v -Z achive
Install (unpack) an archive with compressed files, protecting newer existing files: afio -i -v -Z -n achive
Create an archive with compressed files on floppy disks: find .... | afio -o -v -s 1440k -F -Z /dev/fd0H1440
Create an archive with all file contents encrypted by pgp: export PGPPASSFD=3 find .... | afio -ovz -Z -U -P pgp -Q -fc -Q +verbose=0 -3 3 archive 3<passphrasefile
Create an archive on recordable CDs using the cdrecord utility to write each CD: find .... | afio -o -b 2048 -s325000x -v '!cdrecord .... -'
Extract a single named file from an archive on /dev/tape: afio -i -v -Z -y /home/me/thedir/thefile /dev/tape (If these do not exist yet, afio will also create the enclosing direc- tories home/me/myfiledir under current working directory.)
Extract files matching a pattern from an archive on /dev/tape: afio -i -v -Z -y '/home/me/*' /dev/tape (If these do not exist yet, afio will also create the enclosing directories home/me under current working directory.)
If your filesystem cannot handle files larger than 2GB, but you want to make an archive on that filesystem that is larger than 2GB, you use the following trick to split the archive into multiple files of each 1 GB: find /home | afio -o ... - | split -b1024m - archive. the files will be called archive.aa, archive.ab, etc. You can restore the whole archive using: cat archive.* | afio -i ... - The wildcard expansion by the shell will ensure that cat will read the parts in the right (alphabetic) order.
Mar 9 13:14:54 CST 2005
I personally like to use afio for backup due to it being more robust than tar and you can get a single file out of the archive without having to restore the archive - it also allows splitting of volumes and incremental backups etc.
A good set of scripts to drive this is found in backup21 as in apt-get install backup21 . Its simple but works well with afio. its focus is to backup to a hard disk partition, which i periodically copy to cd as needed. Since the incremental archive is not that large, I find that managing large disks using cd as a backup medium works quite well.
Michael.
NB, tob is also the front end of afio.
documented on: 2005.05.05
http://aa11.cjb.net/hpux_admin/1997/0249.html
I asked "which is better (and WHY?): find|cpio or tar for copying a disk to a slightly smaller drive."
About 15 replies have arrived, most of which (a) pointed out my lack of "-depth" in my example. Valid point. mea culpa. -depth will preserve the time-stamps of directories. Two folks also added the "u" option… immaterial in my case, since i was going to a blank disk.
Mark Jones at Motorola suggested the obvious test (not done due to other time pressures) and replied that tar cannot handle very long pathnames, which -is- a very good reason to use the find|cpio method.
> From: Mark Jones <mjones@pencom.com> > To answer your question, try both with the time command: > time tar -cf - * |(cd /other_place; tar -xf - ) > time find . -xdev -depth -print | cpio -pmdux /other_place > > Tar has a limitation on the number of characters it can > read in a path. Since we have long paths here, we always > use cpio. I don't know if that limitated was fixed > with 10.X. We are still running 9.05.
(as it happened, my copy-over was on a v9.01 system)
Tom Coates (tom_coates@trimble.com) preferred find|cpio for these reasons:
> I doubt there would be much difference in speed, since most of the > time is probably taken up with just transfering the data. This > seems even more likely since you are copying an entire disk. > > I've always used find|cpio, as it gives very good control over > preserving file modification dates, etc. Also, once you get good > at writing find commands, you can filter the copied files to get > only what you want. I've had fits in the past with tar, trying to get > it to copy several trees from different locations, involving symbolic > links into a single new location. Probably the nicest feature of > find|cpio is that you can work out the find command first, to see > exactly what is going to be copied. Then you just repeat the command > piped to cpio to do the actual copying.
Chris Marble (chris_marble@hmc.edu) suggested adding the "-depth", and said:
> I think it's just personal taste. I always recommend the > cpio command and have been posting it for about 2 1/2 years when > anyone asks. On my SGI systems I use dump and restore to copy disks. > I think the cpio could handle CDFs (Cluster Dependant Files) > better than anything else. But CDFs don't expst with HP-UX 10.
Tony Kruse (akruse1@ford.com) suggested a third method (which had crossed my mind, but not in the multi-reader sense he mentions):
> I always use > fbackup -c /usr/adm/fbackupfiles/backup.config -i /usr -f - | \ > (cd /mnt; frecover -Xrf -) > since I can specify 6 filesystem readers to keep the 1 fbackupwriter > busy in my backup.config file.
One reader didn't notice that i was going to a -smaller- disk, and suggested "dd", and another warned me that tar might not do symbolic links (it does).
For what it's worth, my find|cpio of a 1.8-gigs-used disk on a 9000/710 v9.01 took about 1.5 hours. (Digital Equip DSP3210 to HP C2490A)
Something find|cpio did NOT do "properly" was a large number of instances where it couldn't/wouldn't set the file's group to match the original. Usually the old group was "other", and it ended up "sys". Tar slavishly sets the owner/group to their original numeric values, even if those don't exist (if a cross-machine operation).
dick seymour
p.s.: in OpenVMS the command to use is "BACKUP/image in-drive out-drive "
My original posting (-depth added):
>I've got two similar, but not-exactly-equal, disks... and i want to > copy the filesystem (in this instance: not root, not needing to be bootable) > from one to the other. > >Which method is "better", and why? > > cd /old_disk ; find . -depth -print | cpio -pdxm /new_disk > > or > > cd /old_disk ; tar -cf - . | (cd /new_disk; tar -xf - ) > >In previous exercises like this, i've happily used "tar", and the > results seemed to perform properly. However i've noticed postings > here recommending the "find" route... which i'm using at the > moment to migrate users from a screeching 2.1 gig disk to a new 2.06 > gig disk. > >So, what's the difference? Which is faster? Which is fraught with peril? > "tar" would seem to expend more-than-necessary CPU cycles, since its > original goal was an archive file with internal structure, but i'm > primarily concerned with wall-clock time.
Newsgroups: comp.unix.admin,comp.os.linux.misc Date: 31 Oct 2001
chris albert wrote:
> > What are the tools to backup/clone the root volume? > > 'tar' and 'dump' are classic utilities for this. > 'amanda' is another open source utility you might consider. > Take some time to read 'man tar' and you'll see just how powerful > it is. You might also consider getting a cd-writer.
Tar is NOT a backup tool; it is an archive and distribution tool. Use a backup tool to do backups. Tar sets the atime of the files it reads, therefore you'll never be able to detect unused files. Older versions of tar also do not support stopping at filesystem boundaries.
Dump is the best, but several folks already recommended it. Thus I will suggest the second best, cpio.
> > My other concerns are the files under directories /var, /dev, and > > /proc, etc. Should they be included in the backup for the OS > > restore? I know they are not normal files, but I don't know how > > backup tools like tar/cpio can record those "abnormal".
First, /proc is a separate filesystem so it is not an issue if you run cpio on one filesystem. Second, cpio understands file types other than regular files, it's a backup tool after all. Third, because cpio runs within the filesystem, it can be used to backup any type of filesystem. Chuckle, wanna make a backup of a floppy in FAT16 format or a CD-ROM in HSFS with Rockridge extensions? cpio's your tool.
cd / find . -xdev -depth -print | cpio -oa | dd of=/dev/tape obs=16k ...
Extract with dd if=/dev/tape obs=16k | cpio -idum, inspect with cpio -itv, etc.
Dump keeps atime, mtime and ctime intact by working with the raw device driectly, that requires intimate knowledge of the filesystem. Thus there must be a different version of dump for each type of filesystem, or support for several must be compiled in.
Cpio works through the filesystem, as does tar, but it knows how to save the inode of a file before opening it, and how to restore the indoe after finishing. That has an advantage: if the mtime changes during backup, cpio knows. There is a bug in this: the ctime gets changed when the inode gets restored. It's a smaller price than tar's use of atime, butit does make cpio incompatible with dump and with commercial backup software. Everything but cpio uses the most recent of mtime and ctime.
-xdev Don't descend directories on other filesystems.
-o, --create
Run in copy-out mode.
-a, --reset-access-time
Reset the access times of files after reading them, so that it
does not look like they have just been read.
> Tar is NOT a backup tool; it is an archive and distribution tool.
tar with —preserve-atime exhibits similar behavior to cpio. This is, e.g., how amanda calls tar.
Joshua Baker-LePain
In RH62, tar: unrecognized option `—preserve-atime' but has —atime-preserve.
nice tar --one-file-system --atime-preserve -cf /dos/drv_b1/RH62.tgz /