Hardware based data recovery is definitely a plus in a volatile environment such as the Seneca Lab.
Without even considering the possibility of malicious attacks - rather thinking about accidental or inadvertent mishaps - this Lab has people who are new to the system and need to experiment to get
their work done. Accidents do happen: people delete files and sometimes something gets trashed that should have been left alone - everybody who spends a lot of time working on computers has done it at some time. So in the Seneca Lab it makes good sense to take this proactive step.
The same surely cannot be a good thing when applied to workstations that are used by people doing serious work that involves the need to set up special environments and have job-specific tools on their computer. I would have to think that traditional timely backups would provide a sufficient protection for recovery.
This Lab was useful in that it actually demonstrated that the recovery does work. If somebody told me that it worked but I didn't prove it I would likely have a slight doubt in the back of my mind - does it really work; maybe it works sometimes...
The one problem that I had with the lab (the assignment) was that my scp command doesn't seem to be doing what i thought it would. The command (scp lab00.txt xxxx@xxxxxx.senecac.on.ca )
executes without any message - no challenge for password - but doesn't copy the file. I am executing the command from home and my network connection is working as i could mail the file to myself. I just tried scp xxxx@xxxxxx.senecac.on.ca: laboo.txt it connects, authenticates but gives the message 'scp: .: not a regular file'
2 comments:
Louis, I think the scp command was missing a colon and path on the remote host -- use "scp lab00.txt user@hostname:/path/to/file"
When the colon and remote path are left out, you end up with a file on the local machine named "user@hostname".
Thanks Chris
and you are right :)
Post a Comment