adcentrix
asked on
Simple backup from remote linux server to a windows 2000 workstation...
I need to implement an easy to use backup solution for a client that it's running a remote linux server and wants to backup all data on the server to his private network (window$ 2000) every 2 days ...
I tried to do by creating tar.gz files and then copying via FTP... does anyone know a faster way to do it? The files are close to 570mb after they have been compressed by gzip...
Thanks
I tried to do by creating tar.gz files and then copying via FTP... does anyone know a faster way to do it? The files are close to 570mb after they have been compressed by gzip...
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ok, so what you are saying is your client wants to backup his data on the remote linux server.
1, A script should be put together that is run as a cron job every two day's that compresses all the documents on the Linux server that need backing up, into a single archive and puts that new compressed archive into a specific folder that can be accessed via FTP. The choice of compression algorithm is up to you. The compression method can also serve as your encryption, you could even password restrict the archive if you use zip. For someone wanting to itercept the data in transit they would need to get a copy of the entire archive. At 570MB they would have to really want a copy of your data! The shear size and complexity of the transition would generally put off most of your average miscreant haxors. Your FTP password is addmitedly exposed, but it would require some one to be monitoring your connection 24/7 in order for them to grab the password. Is the data really that seretive?
2, The local Windows server could be setup with a scheduled task to access the remote Linux server on the day that it is not compresing the data via FTP. And again using a script that utilizes (FTP, get) download the backed up archive to the local server.
Overall my suggestion is, that you get a Linux server for your Local office and setup RSYNC and use SSH/SCP to transfer your archives, the compression method I would use would be bz2.
1, A script should be put together that is run as a cron job every two day's that compresses all the documents on the Linux server that need backing up, into a single archive and puts that new compressed archive into a specific folder that can be accessed via FTP. The choice of compression algorithm is up to you. The compression method can also serve as your encryption, you could even password restrict the archive if you use zip. For someone wanting to itercept the data in transit they would need to get a copy of the entire archive. At 570MB they would have to really want a copy of your data! The shear size and complexity of the transition would generally put off most of your average miscreant haxors. Your FTP password is addmitedly exposed, but it would require some one to be monitoring your connection 24/7 in order for them to grab the password. Is the data really that seretive?
2, The local Windows server could be setup with a scheduled task to access the remote Linux server on the day that it is not compresing the data via FTP. And again using a script that utilizes (FTP, get) download the backed up archive to the local server.
Overall my suggestion is, that you get a Linux server for your Local office and setup RSYNC and use SSH/SCP to transfer your archives, the compression method I would use would be bz2.
Agree with paddyhaig in his/her last remark.
Use rsync (with SSH as transport layer), to do "incremental" backups (using builtin rsync features). Since the files are remaining on the target (?!) you never have to schedule "full" backups.. The first one will be full automatically.
Rsync have several methods (of varying performance) to choose from when doing "incremental" transfers. It's all in the docs. I even use rsync for local periodic incremental copy to other disks with great(!) speedup. The speedup would depend on how much data has changed since last backup of course. In my referenced with disk copy I've reduced 3-4 hours to 1-5 minutes.
Possibly you could just install openssh and rsync on the windos machine (www.cygwin.com) and off you go :-)
You would wan't to setup SSH public key authentication to be used from the Windos side, and initiate the synchronization from there (via scheduled task or "at" job or whatever).
Or install another unix/linux node at the "office" to do the job as suggested before. (same proceedure with public key authentication etc)
/bummer
Use rsync (with SSH as transport layer), to do "incremental" backups (using builtin rsync features). Since the files are remaining on the target (?!) you never have to schedule "full" backups.. The first one will be full automatically.
Rsync have several methods (of varying performance) to choose from when doing "incremental" transfers. It's all in the docs. I even use rsync for local periodic incremental copy to other disks with great(!) speedup. The speedup would depend on how much data has changed since last backup of course. In my referenced with disk copy I've reduced 3-4 hours to 1-5 minutes.
Possibly you could just install openssh and rsync on the windos machine (www.cygwin.com) and off you go :-)
You would wan't to setup SSH public key authentication to be used from the Windos side, and initiate the synchronization from there (via scheduled task or "at" job or whatever).
Or install another unix/linux node at the "office" to do the job as suggested before. (same proceedure with public key authentication etc)
/bummer
"CygWin" along with Rsync is a great suggestion!
The rsync remote-update protocol allows rsync to transfer just the differences between two sets of files
across the network link, using an efficient checksum-search algorithm described in the technical report
that accompanies this package.
Some of the additional features of rsync are:
o support for copying links, devices, owners, groups and permissions
o exclude and exclude-from options similar to GNU tar
o a CVS exclude mode for ignoring the same files that CVS would ignore
o can use any transparent remote shell, including rsh or ssh
o does not require root privileges
o pipelining of file transfers to minimize latency costs
o support for anonymous or authenticated rsync servers (ideal for mirroring)
The rsync remote-update protocol allows rsync to transfer just the differences between two sets of files
across the network link, using an efficient checksum-search algorithm described in the technical report
that accompanies this package.
Some of the additional features of rsync are:
o support for copying links, devices, owners, groups and permissions
o exclude and exclude-from options similar to GNU tar
o a CVS exclude mode for ignoring the same files that CVS would ignore
o can use any transparent remote shell, including rsh or ssh
o does not require root privileges
o pipelining of file transfers to minimize latency costs
o support for anonymous or authenticated rsync servers (ideal for mirroring)
I don't know how rsync under cygwin handles device files and links when saving to NTFS though.. Could mean problems in a restore situation.
Perhaps another linux/unix node is the safest bet anyway?
/b
Perhaps another linux/unix node is the safest bet anyway?
/b
Remember to encrypt your files, if you don't it'll be extremely easy for any hacker to intercept and copy all the files you are transfering, encryption will add a little bit more of security.
You could also set-up a VPN (virtual private network) which should make the communications more secure, and transfering the files through there, this would, like I said, decrease the chances of a hax0r getting to your files.