how do i scp .dotfiles??
freebsd at edvax.de
Sun Aug 29 13:41:27 UTC 2010
On Sat, 28 Aug 2010 18:05:31 -0700, "'Gary Kline'" <kline at thought.org> wrote:
> at least for me, gtar fails to pick up dotfiles. rsynx copies
> =everything=, and it looks like the test rsync script i posted
> last night was working all along. it was So fast that i assumed
> it was bombing entirely. i will 2-ck a few more files before i
> am sure.
> a question to the list is how can i copy ALL of /home to my new
If it is the 1st copy, I'd suggest using dump + restore. This
of course will only work if your /home is a separate partition
on both systems. Partition size doesn't matter as long as the
size of the target partition is at least the size of the used
data on the source partition.
You basically umount /home and then use
# dump -Lauf0 home.dump /dev/ad0s1f
to obtain the data; you can also use - instead of the actual
file home.dump to pipe the data directly to a transfer via
scp. On the target machine,
# cd /home
# restore -rf /where/is/home.dump
You can connect both commands with ssh so you can directly
dump + restore from machine A to machine B, given that SSH is
It then would be something like this:
# dump -0Lauf - /dev/ad0s1f | ssh 10.0.0.10 "cd /home && cat | restore -rf -"
In this example, 10.0.0.10 is the IP of the target machine, and
you're issuing the command from the source machine, with /home
Note that dump requires the DEVICE NAME of the device where /home
is mounted on, and restore will put everything into the CURRENT
DIRECTORY. The source device must NOT be mounted, but the target
directory must be mounted and accessible.
You CAN, however, leave /home mounted, and dump will create a
snapshot that identifies /home as at the starting point in time;
changes during backup won't be reflected in the target. It CAN
be possible get inconsistencies during creation of the snapshot
if there's heavy activity on /home, so it's usually "the safe
way" to umount /home before reading from the device file.
This method makes sure you will get ALL files with their exact
properties (permissions, flags, dates).
See 18.2.1 here:
For any further synchronisation, I would go with rsync.
There is also another interesting tool in ports: It is called cpdup.
It can also be used for synchronisation, and it has the interesting
feature (can be configured of course) that it won't delete files
in the target that have been deleted in source since the last run.
In this case, your target data will always grow, and if you acciden-
tally deleted something, it will sill be there.
> and to you, matthew, does --delete rm out of date files
> or directories?
The --delete parameter will have rsync delete files on the target
that are NOT part of the source files, but only relative to the
subtree you are transfering.
E. g. on your target machine you already have
from last time you synchronized, and you have the files
as never versions in the source, and you also deleted meow.c here
because you don't need it anymore. Now if you rsync the src/ dir
to the target machine, --delete will remove meow.c from the target,
and rsync will of course update foo.tex and bar.tex.
The --delete makes sure that the copy is of 1:1 kind, instead of
> what about ?VS, given that i have virtually
> everything under [CR]VS control? slightly offtopic is that i
> accidently rm'd a file on tao one morning after a few minutes work.
> a copy was safely croned to ethic.....
A good suggestion. I did use cvsup (from ports) in the past for
revision control and "idiotproof storage" for most stuff that
I created. It is very helpful, not just for "recovering" accidentally
deleted files, but also for progress check and "rewinding" changes.
It's a great tool for keeping configuration files also. Backing it
up gives you a versioned, ordered, one-tree consistent file collection.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions