USB2 and USB3 flash keys have been growing in capacity and falling in price. They make a useful backup option, where the backup size is larger than optical media, but smaller than readily available tape drives. I would consider USB2 up to 100 GB (1 hour at 30 MB/s). USB3 is a plausible backup option up to about 1TB (1 hour at 300 MB/s). |
Supported. Subject to the following requirements
| Dave got us a new backup device for the HP servers a couple of years back - a RDX unit - to test. In effect, the cartridges are 2.5" SATA drives. So, I guess they're kinda similar to the old Tandem AD-PACs (if you still remember them?). The reason for looking at these is that DAT drives are almost non-existent, and Ultrium drives are very expensive for (smaller) customer servers - especially when you have to add an external housing (the DL380s won't take an Ultrium drive internally). Well, we've gotten one here, and it works quite nicely - when the drive/cartridge is changed from a NTFS partition to an ext3 one! Also nice, is that you can't eject the drive/cartridge whilst it's mounted. I just need to ask, how long are we looking at to include support for such in the admin scripts? I would suggest that customers continue to run a clone, but then either copy that clone off to a single file on the cartridge, or run another clone-to-file straight afterwards. It would also be nice to be able to hold multiple backups on each cartridge (space allowing of course)..... so, a Monday cartridge could hold the last 5 Monday's backup files FOR EXAMPLE. None of this is going to be too difficult, but I just need to know some sort of timescale if possible. I provided you with relevant information about the device entries on other e-mails, but heard nothing more. |
Most available RDX drives use a USB2 or USB3 interface and will be picked up as a removable device on the USB bus. Tandburg produce an internal enclosure with a SATA3 interface, would need testing if support is required.
Cartridges are available up to at leased 2TB. For a USB2 enclosure, the interface will limit the speed at around 30 MB/s. For an enclosure with a USB3 or SATA connection, I/O speed limit will be down to the cartridge chosen.
Where you do not need gigantic storage capacity. Optical drives, and their media may work out the cheapest option. With a slightly slower write speed special Archive Media is available, with a claimed data retention time of 1,000 years. That is the longest retention of any modern media. |
Support has been added. Subject to the following requirements.
| System backups on Linux systems:- Initial testing looks good, but it needs full testing/restore to confirm a restore following a disaster (good documentation/instructions needed for (hardware) support to be able to restore please). I'm still a little confused why we couldn't have put the simple backup routine in place that I mentioned years ago. It may not be as fully comprehensive as we'd like, but there is no immediate NEED for a bare-metal recovery routine. In the event of a complete server failure, we generally reload the new server (as it gives us an opportunity to upgrade the OPSYS) and then overlay everything else (applications etc.). It's absurd that we still don't have an option for customers to use! |
Should get both files and meta data on file systems.
Needs a very thorough test.
| Making restore CD/DVD/USBKey options not valid yet? |
Option works. Need to verify that all required packages are written to device.
| CentOS 6.3+ - tape device (st0 for example) now belongs to "tape" group, rather than "disk". User "rr" will need to belong to that group too. |
It does.
|
If an EDI routine tries to start when all runtimes are in use, it will fail. This causes problems especialy with RRlive. |
This is partly a user issue, if the customers purchased an adequate number of software licences, and trained their users to log out when they were not using the system it would be far less of an issue.
That said, we can potentially track the number of sessions, and block user oriented sessions from being started when there are only a limited number of licences free.
| Restoring from a clone, you could (and usually would) end up with newcobs being older than cobs. Maybe simply purge JUST those 2 directories (in the clone area) prior to a clone? (even if it was only on a weekly basis?) This has proven to be an issue with a customer and Support on more than one occasion! This is also an issue for those customers wanting to use an old machine, and if we rsync the clone area from one machine to the other. Also, if a load of temporary files are moved to a sub-directory (under the live data directory), prior to deletion, they get copied to the clone area, but never deleted from there. As a consequence, the copy-to-tape process can be vastly bigger than necessary - too big for a tape in cases! Really need an option to clean out the clone area..... finding a number of customers who have HUGE amounts of data in their clone areas (which often doesn't exist in the live area). Again, rsync would negate this. |
| How about using rsync (with the --delete option) rather than cpio? Using rsync would negate the need to purge anything in the clone area, and make restoring much easier and neater! Might even make it quicker?! |
Depends on how cluttered the RoadRunner area is, rsync really does not like large directories, say any over 5,000 directory entries.
| Could they be included in the backup log when a clone-to-file is performed? |
They should be. if they are not then it should be a quick fix.
| "unsuccessfull" - should be "unsuccessful" |
| If clone fails with a "2", and retries from scratch - "atempt" should be "attempt" |
| Issues with "relative" symbolic links - causes clone-to-file to fail, although clone succeeds. An issue, because having to "absolute" path the links could cause issues in the future, especially if copying the live data area across to a test area! |
The copy company routine should be smart enough to cope. Extra use case for QA/QC testing.
| Clone backup not reporting free space correctly - looks like column 3 is being reported, but should be column 4? |
Fixed. Uses local logic rather than the function freespace
from size.lib. Which looks to have been fixed back in 2010.
| Be able to set these within rr.var, so "-Hnewc" could be used for example (support for files >2GB/4GB etc.) |
| For the support of bigger files? "tar" can accept a list of files too. (again, mentioned years ago) |
The backup sections of the scripts will be receiving a major rewrite. Ahead of this the 2010 script changes included code to detect presence, and version of a number of archive packages. This is complicated by the fact that there are several packages, which are functionally different but can install under the same command name.
Am looking for confirmation that the detection code reports correctly in the out put from
"Show configuration" on the "SYSTEM utilities menu".
Multimode archive commands ------------------------------ RT_pax /usr/bin/pax ver 1.5.2 RT_spax /usr/bin/spax ver 1.5.2 RT_opax /usr/bin/opax ver 3.4 Pipeline archive commands ------------------------------ RT_bsdcpio The program bsdcpio was not found on this system RT_sysvcpio The program sysv/cpio was not found on this system RT_cpio /usr/bin/cpio ver 2.11 Best program found in class spax Commandline archive commands ------------------------------ RT_star /usr/bin/star ver 1.5.2 RT_gtar /bin/gtar ver GNU_1.26 RT_ustar /usr/bin/ustar ver 1.5.2 RT_tar /usr/bin/gtar ver tar-1.26-29.el7.x86_64 Best program found gtar Other archive commands ----------------------- RT_rsync /usr/bin/rsync ver 3.0.9 RT_shar ver Compresion tools ------------------------------ RT_xz /usr/bin/xz RT_zip /usr/bin/zip RT_gzip /usr/bin/gzip RT_bzip2 /usr/bin/bzip2 RT_pbzip2 /usr/bin/pbzip2 RT_lzop /usr/bin/lzop RT_compress /usr/bin/compress Parrity file commands ----------------------- RT_par2 /usr/bin/par2 RT_par2create /usr/bin/par2create RT_par2repair /usr/bin/par2repair |
| Upon backup failure - "Please Correct problem and then try agian" should be "Please correct problem and then try again" |
Can not find "agian" in any file, must have been fixed.
| "Target directory for Clonning" in rr.var should be "Target directory for cloning" |
Fixed
| on the dataset menu, I think it's best to change the stop EDI options from E/e as users can (and DO) take it by mistake, thinking it will exit them! It's happened a number of times..... |
What would people like instead?
Changed to "s" and "S".
|
Some more details......
- get current directory for "in-use" relativity from a "ps -eaf |grep rel" (base directory is usually /usr/relativity/, but not always!) - start script is "RUNACTIVE" in base directory - stop script is "STOP" in [base-directory]/`cat .active` (to give [active-version] directory) - connection report is [base-directory]/[active-version]/connect.log - event report is [base-directory]/[active-version]/event.log |
| pnglib needs including on set please, and maybe a line change?:- Last="$(${DATE} -r /usr/local/httpd/cgi-bin/pnglib "${Last_Format}" )" to Last="$(${DATE} -r /var/www/cgi-bin/pnglib "${Last_Format}" )" |
As far as i can see that was fixed 25/7/2013
png-lib and MyIp should both be copied to both tar and iso sets.