|
Size: 1604
Comment:
|
← Revision 5 as of 2012-01-03 23:03:06 ⇥
Size: 1296
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 27: | Line 27: |
| ssh-agent > .agent edit .agent to remove the last line (echo) source .agent ssh-add ~/.ssh/id_rsa to verify: ssh-add -l and if it picks up the wrong one (id_dsa) remove it with ssh-add -d Check that the connection works: ssh 40m@ldas-cit.ligo.caltech.edu /bin/ls /archive/frames/trend/minute-trend/40m This also allows to to see the last minute-trend frame that was archived. This is all you need to do. |
login to controls@fb40m cd /cvs/cds/caltech/scripts/backup read and follow the instructions in 000README.txt |
/cvs/cds/caltech/scripts/backup/000README.txt AJW, 1/17/06 Stuart Anderson has set up an ssh connection between fb40m (our framebuilder, on which our raid array /frames is mounted) and the LIGO data /archive at CACR in Powell-Booth. Assuming the ssh-agent is running, a daily cron job on fb40m (currently, daily at 3:30 AM, see "crontab -l" which should show a line like this: 30 03 * * * /cvs/cds/caltech/scripts/backup/rsync.backup < /dev/null > /cvs/cds/ caltech/scripts/backup/rsync.backup.log 2>&1 ) runs the command /cvs/cds/caltech/scripts/backup/rsync.backup which does an incremental backup of /frames/minute-trends and /cvs/cds , using rsync. It overwrites the log file /cvs/cds/caltech/scripts/backup/rsync.backup.log which should contain, at the very least, a day's worth of minute trends and burt snapshots. ________ If fb40m is rebooted, we likely will have to restart ssh-agent with the correct key. login to controls@fb40m cd /cvs/cds/caltech/scripts/backup read and follow the instructions in 000README.txt The job, scheduled with cron (see "crontab -l") will run overnight. The next day, look at rsync.backup.log and it should report the day/time that it last ran, and that it archived recent trend data files (at least).