Topic: won't backup to disk - flexbackup

[Rob Wellesley]

Hi

followed des duggans how to and ended up with this /sbin/e-smith/backup

#!/bin/sh

#------------------------------------------------------------
# DO NOT MODIFY THIS FILE! It is updated automatically etc.
#------------------------------------------------------------

# Tape backups are enabled

export PATH=$PATH:/sbin

/sbin/e-smith/signal-event mysql-delete-dumps > /dev/null 2>&1
/sbin/e-smith/signal-event mysql-dump-tables > /dev/null 2>&1
mount /mnt/backup
/usr/bin/flexbackup -fs all

/sbin/e-smith/signal-event mysql-delete-dumps > /dev/null 2>&1

umount /mnt/backup

#------------------------------------------------------------
# TEMPLATE END
#------------------------------------------------------------

But it don't backup to the share (i can mount and browse from command line ok) and cron mailed me this...

flexbackup version 0.9.8
/etc/flexbackup.conf syntax OK

|------------------------------------------------
| Trying "mt defblksize" instead of "mt setblk"
Error setting block size
Neither of these commands worked:
  mt -f /dev/nst0 setblk 0
  mt -f /dev/nst0 defblksize 0

Any ideas??..              Rob

[Greg O]

I had similar problems, but an upgrade to SME 5.1.2 and following the howto again exactly, start to finish, fixed the problem. For the meantime when I couldn't backup, I simply shared a drive (as per part of Des' howto) on a client workstation, mounted it, and copied the entire contents of /home/e-smith/files to it, ignoring the 'could not preserve permissions' errors.

Now I have another problem. Every time a backup reaches 1.99GB it stops with the error below. It seems to be regardless of the projected size of the backup - I've had between 5Gb and 10Gb of data - same problem.
  DUMP: Broken pipe
  DUMP: The ENTIRE dump is aborted.

For two full logs, see:
http://gw.carey.wa.edu.au/20020322.txt
http://gw.carey.wa.edu.au/20020323.txt
TIA,
Greg.

PS I'd also like to know what the problem was with "Error setting block size" but for the moment it's fixed for me (and hopefully for Rob), so if no-one can help with that little gem, then so be it.

[Filippo Carletti]

You're hitting the 2G file size max of SME.
Nothing to do.

Setting block size refers to the tape, don't worry.

[René]

I had the exactly the same problem as Rob

But I think I am not hitting the 2G file size of SME.

[root@sme2 /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             2.0G  335M  1.5G  18% /
/dev/sda1              15M  2.9M   11M  21% /boot
[root@sme2 /]#

Any ideas??

René

[Greg O]

What about partial backups then Filippo? Is there someone out there who's writing to-tape or to-desktop web-panel options that include, eg, "users a*-h*, h*-p*, q*-z*" in 3 separate files? With the obvious benefit of different partial backups over different days. Hmm, should I simply go ahead and look at flexbackup syntax and do it myself? (if it's easy enough...)

Because surely there are 3 major (size-wise) parts to an e-smith system: users, ibays, and everything else?

Rene, as per what Filippo said, that error message is a tape thing, so if you're not backing up to tape, ignore it. I would suggest what I tried though, go through the whole howto again, start to finish, removing and re-creating any files/dirs. If you're using e-smith 5.x, there's a small change - in /etc/e-smith/templates-custom/etc/cron.d/
instead of the file 'backup' under the folder 'backup', simply create the file 'backup' in the ./ directory.

Ie 4.x:
dir: /etc/e-smith/templates-custom/etc/cron.d/backup/
file: /etc/e-smith/templates-custom/etc/cron.d/backup/backup
5.x:
dir: /etc/e-smith/templates-custom/etc/cron.d/
file: /etc/e-smith/templates-custom/etc/cron.d/backup

Cheers,
Greg.

[Des Dougan]

Filippo,

I think actually it's the desktop OS causing the problem here. The SME limit seems to come into play when restoring. Greg, is the desktop being backed up to a Win 9x/ME system? I think this is a FAT32 limitation.

Des Dougan

[Filippo Carletti]

Ok, I'll try to be clear.
1. flexbackup to file on sme: there's a 2 Gb file size limit on SME
2. desktop backup to some win pc: win filesystem limits and more (see below)
3. flexbackup to tape: ok

The best way to overcome the 2 Gb limit would be upgrading to kernel 2.4.
When testing desktop backup to a pc, I found a 4 Gb limit, which seems to be related to network download. I still have to test a non win client and a server driven solution (automated backup to desktop).

I would like to have somebody confirming the 4 Gb limit.

[Matt]

I've been trying to backup to desktop and it also stops at 3.99 GB (I'm using a FAT32 partition on Windows 2000). Would this same thing happen if I configured backup to disk and used that instead of backup to desktop? If not, how can I backup 4+ GB of files?

[Tom Keiser]

Change your FAT32 partition to NTFS. FAT32 has a 4GB single-file size limit.

[Greg O]

Ok, the next obvious question for me is: Is there a way of making flexbackup use 'volumes' like Winzip does on a diskette? I've perused the flexbackup helpfile, even crashed flexbackup a couple of times. I've also been completely confused by all the options in /etc/flexbackup.conf

Surely there is someone out there who knows this stuff (or knows enough to work it out) - can I tell flexbackup to save x number (however many it takes) of 2Gb volumes of backups for each job?

Of course, you'd (potentially) later need to be able to restore those volumes... again - how?

Thanks for the dialog - it's all been very helpful. Just trying to solve my backup problems once and for all (:

TIA,
Greg.

[Bruce Friedman]

I have a Windows XP box with NTFS file system.  It is stalling at 4GB as well.  I have read the MS KB article:

Windows NT File Size and Partition Size Limits
http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q93496

Which states that the limit is 2^64 on NTFS, however, I'm not seeing this.  Has anyone else seen this behaviour on NTFS?  Any ways around a backup to desktop of greater than 4GB?

[Tom Keiser]

IIRC, there's an issue with NTFS. If your installation partition is being used, it will have a 4GB limit because of the way the install and subsequent file system conversion works. I seem to remember that NTFS partitions newly created from a running vers of windows will not have the limitation. I don't recall seeing anything about a workaround for this, and I can't remember where I saw it, but it might put you on the track of something.Bruce Friedman wrote:
>
> I have a Windows XP box with NTFS file system.  It is
> stalling at 4GB as well.  I have read the MS KB article:
>
> Windows NT File Size and Partition Size Limits
> http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q93496
>
> Which states that the limit is 2^64 on NTFS, however, I'm not
> seeing this.  Has anyone else seen this behaviour on NTFS?
> Any ways around a backup to desktop of greater than 4GB?

[Bruce Friedman]

The NTFS installation partition issue may have been part of the problem, but it did not solve the problem!

I repartitioned my disk with a smaller installation partition and created a new partition out of the free space from within WXP.  I then created a logical drive and formatted it with NTFS.  Thus it should support files of size 2^64 or less.

When running the backup from the server manager, the problem showed up again at 3.99GB. I thought I knew what was wrong because I figured that the temp files were being stored on my original installation partition which still may have this limitation of 4GB.

Then I thought I would get smart and use Des Dougan's backup script because it does not create a temp file - it mounts a shared directory under SMB and writes to it directly (it is faster, too).

Still halts at 4GB.  I received the following note from Des that indicates the problem is in the RedHat kernel.

>My understanding is that it's a kernel limitation. There has been traffic on this >subject in the past on the e-smith lists which might explain it better than I can, >but my understanding is that this is a limitation of the stock Red Hat kernel
>(they have an Enterprise kernel without this limitation, IIRC). It's not an NT >issue, because the problem is with a filesystem you've mounted on your server >via Samba.

If that is true, I'm not really enthusiastic about swapping out the kernel and no longer being on the main SME branch.  Anybody have ideas on how to break the streaming backup into 4GB or smaller files on the fly?  2GB would probably be the best size, since FAT32 supports that size.

Tom Keiser wrote:
>
> IIRC, there's an issue with NTFS. If your installation
> partition is being used, it will have a 4GB limit because of
> the way the install and subsequent file system conversion
> works. I seem to remember that NTFS partitions newly created
> from a running vers of windows will not have the limitation.
> I don't recall seeing anything about a workaround for this,
> and I can't remember where I saw it, but it might put you on
> the track of something.

[Greg O]

How about doing a flexbackup to local disk (of course, this presumes you've got more than 50% free disk space, but it's a start), then using tar or some other sort of voluming tool to pop into byte-sized chunks to send off to your backup device? (ie 2Gig/4Gig or whatever you choose).

Problem is, I don't know how. I've read the tar docs, and got nowhere. Specifically,
http://www.gnu.org/manual/tar-1.12/html_node/tar_42.html
says very little about the -M option. I'm guessing someone out there knows how to use tar WAY better than I do. I'm not even sure the -M option is the one needed.

still hoping to fix backup probs, (or should I say, complete non-functionality)

Greg.

[Bruce Friedman]

Greg,

This has the same problem as mentioned earlier, if the problem is in the ext2fs on Linux 2.2.19.

I found the following article referencing a 2GB file size limit:

http://groups.google.com/groups?q=ext2fs+%22file+size%22+maximum&hl=en&scoring=d&selm=20010411124006.C2072%40navel.introspect&rnum=5

Q:  Is there any way around the 2GB file-size limit in Linux?  Are there
    any stable patches to fix it?

A:   Short answer:  In a practical sense, no.  The 2GB limit is deeply
    embedded in the versions of Linux for 32-bit CPUs: in GNU libc, in the
    Linux kernel's filesystem drivers and VFS layer, in the fundamental
    design of some filesystems, and in the function calls used in the
    compiled applications and utilities furnished in (and for) typical Linux
    systems.  There is thus currently no VA-supported configuration.  Long
    answer:  All Linux ports for 32-bit CPUs (i.e., all architectures other
    than Alpha and IA-64) use 32-bit integers for file access and locking,
    yielding a maximum size of 2^31 - 1 =3D 2GB.  Creating a workaround for
    this situation without breaking existing code is an obstacle for all
    32-bit Unixes[1], whose creators met to design a standard 64-bit
    file-access programming interface, at a meeting sponsored by X/Open,
    called the Large File Summit (LFS)[2].  The resulting large-file
    standard and related system calls are likewise called LFS.

While this refers to VA Linux, I'm assuming it applies to RedHat 2.2.

Given that, if you can't write a bigger file directly, then flexbackup would have to be modified to split the file on the fly, so there never was a file created bigger than 2GB.  

However, all this begs the question, if 2GB is the limit, then why do we see problems at 4GB - that's one more bit than 2GB?

Greg O wrote:
>
> How about doing a flexbackup to local disk (of course, this
> presumes you've got more than 50% free disk space, but it's a
> start), then using tar or some other sort of voluming tool to
> pop into byte-sized chunks to send off to your backup device?
> (ie 2Gig/4Gig or whatever you choose).
>
> Problem is, I don't know how. I've read the tar docs, and got
> nowhere. Specifically,
> http://www.gnu.org/manual/tar-1.12/html_node/tar_42.html
> says very little about the -M option. I'm guessing someone
> out there knows how to use tar WAY better than I do. I'm not
> even sure the -M option is the one needed.
>
> still hoping to fix backup probs, (or should I say, complete
> non-functionality)
>
> Greg.

[Bruce Friedman]

Greg,

I have modified Des Dougan's desktop_backup.sh script to use tar multi-volume backup successfully.  There are assumptions about the directory to backup to - it is on your workstation and is SMB mounted to /smebackups.  The backup scripts contained here are expected to be located in /root/backup.  The size of the fragments used is 1GB.  When I tried to get close to 2GB, I ran into file size limitations in tar, however I think that could be tweaked to get under the limit if you wanted to.

You can then create a cron job for this to automate it - however your workstation must be available so that the directory can be mounted.

regards,
Bruce Friedman

Here is backup.sh
-------------------cut-------------
#!/bin/sh

if [ $# -lt 4 ]; then
        echo "Usage: $(basename $0) "
        exit 1;
fi

SMBHOST=$1
SMBSHARE=$2
SMBUSER=$3
SMBPASS=$4

#
# FRAGSIZE is the size in 1KB of the uncompressed file fragment
# value of 1048576 is 1GB
#
FRAGSIZE=1048576


mount -t smbfs -o username=${SMBUSER},password=${SMBPASS} //${SMBHOST}/${SMBSHAR
E} /smebackups

/bin/echo 1 > /root/backup/.lastfile
/bin/rm -f /smebackups/backup.tar

/sbin/e-smith/signal-event mysql-delete-dumps
/sbin/e-smith/signal-event mysql-dump-tables

/bin/nice /bin/tar --directory / --create home/e-smith etc/e-smith/templates-custom etc/e-smith/templates-user-custom etc/passwd etc/shadow etc/group etc/gshadow etc/smbpasswd etc/ssh root/.ssh --tape-length ${FRAGSIZE} --multi-volume -new-volume-script /root/backup/newvol.sh --file=/smebackups/backup.tar

# the last fragment needs to be named with the last sequence number
a=/bin/cat /root/backup/.lastfile
/bin/mv -f /smebackups/backup.tar /smebackups/backup.$a.tar

/sbin/e-smith/signal-event mysql-delete-dumps

umount /smebackups
-------------------cut-------------

Here is newvol.sh
-------------------cut-------------
#!/bin/sh

a=/bin/cat /root/backup/.lastfile

#------------------------------------------------------------
# You would think that tar'ring to the local drive and
# gzip'ping there would be the fastest method, but you would
# be wrong.
#
# Experimental results are that tar directly to samba share is
# only slightly slower (14 minutes for 1GB versus 13 minutes locally)
# than local hard disk storage.  Network was 100Mbps switched ethernet
# local server is Celeron 660, remote is P4-1400
#
# Tests also indicated that gzip was producing less than 10%
# compression on the sample files.
#------------------------------------------------------------
#
#/bin/nice /bin/gzip -f /tmp/backup.tar
#/bin/mv -f /tmp/backup.tar.gz /smebackups/backup.$a.tar.gz

/bin/mv -f /smebackups/backup.tar /smebackups/backup.$a.tar

a=/usr/bin/expr $a + 1

/bin/echo $a > /root/backup/.lastfile
-------------------cut-------------

[Greg O]

Thank you for the desktop-backup alternative, it's almost exactly  what I was talking about/asking for (:

But, given your comments (below) that flexbackup needs to do the splitting, not something afterwards (ie tar) - now I'm really out of my depth. I've crashed flexbackup a few times (is that supposed to be possible?) playing with settings/options, trying to figure out multi-voluming. In fact, is multi-voluming possible? Surely you can also play with tape-size in flexbackup as well as tar??

Hmm, even Darrel's contrib
http://www.myezserver.com/downloads/mitel/howto/flexbackup-howto.html
didn't really help me.

> Given that, if you can't write a bigger file directly, then
> flexbackup would have to be modified to split the file on the
> fly, so there never was a file created bigger than 2GB.

Cheers for all of the feedback on this,
Greg.

[Bruce Friedman]

Greg,

I am not sure why you would want to use flexbackup for backup to a desktop if the tar command includes all the directories you wish to backup.  What does the tar solution not include that you wish to utilize from flexbackup for backups to files (desktop)?

regards,
Bruce Friedman

Greg O wrote:
>
> Thank you for the desktop-backup alternative, it's almost
> exactly  what I was talking about/asking for (:
>
> But, given your comments (below) that flexbackup needs to do
> the splitting, not something afterwards (ie tar) - now I'm
> really out of my depth. I've crashed flexbackup a few times
> (is that supposed to be possible?) playing with
> settings/options, trying to figure out multi-voluming. In
> fact, is multi-voluming possible? Surely you can also play
> with tape-size in flexbackup as well as tar??
>
> Hmm, even Darrel's contrib
> http://www.myezserver.com/downloads/mitel/howto/flexbackup-howto.html
> didn't really help me.
>
> > Given that, if you can't write a bigger file directly, then
> > flexbackup would have to be modified to split the file on
> the
> > fly, so there never was a file created bigger than 2GB.
>
> Cheers for all of the feedback on this,
> Greg.

[Greg O]

Well, flexbackup is very e-smith-compliant, ie runs with the ready-running webpanels etc etc. I guess my main concern is come restore time, what do I do? Do I install e-smith first, or just format a machine with ext2, or.... ? It just opens up all new ground again instead of going with the tried and true methods that e-smith supplies.

If configured correctly, a flexbackup restore for me would simply entail:
1. Install SME 5.x (or latest) on a blank machine
2. Set up the backup device (eg /mnt/backup in fstab or whatever)
2. Copy across the backup/restore custom template and expand it
3. Run the restore.

Hate to bite the hand that feeds me -- the howto you provided (with a couple of minor changes to suit my particular setup) is working perfectly! -- but I don't really have much experience with backups, so I'm being cautious about getting off the beaten track.

Cheers,
Greg.

[Rob Wellesley]

Bruce Friedman wrote:
>

> The size of the fragments used is 1GB.  

This is great work..  Thank you

Can you indicate how one does a reinstall from the fragments?


TIA  Rob

[Bruce Friedman]

Greg,

I'm glad the procedure worked for you, too.  Don't worry about biting the hand that feeds you - I don't take this personally

Your point about staying with existing SME procedures is a good one, and one which I usually want to follow, too, for the same reasons you give.

However, in this case, backup to desktop is not a working feature on the stock SME server when your backup file size exceeds either 2GB or 4GB - in my case it appears to die at 4GB.

I imagine it might be possible to build a flexbackup like tar file that flexbackup would restore, but I was overwhelmed by the size of the flexbackup script - thousands of lines of perl, and I wouldn't want to venture into that solely for allowing a restore.

The process I would use to restore (haven't tried it BTW) is to follow your list
below, including mounting of the backup directory like in the script I gave, and then run the following command:

tar xf backup.*.tar

I suppose that wouldn't be too difficult to put in a script that would be accessible from the admin web panels.  Could start with Darrell May's restore-now RPM as a base...

BTW - if you only want to see what files are in the backup set, you can issue the following command to list them all:

tar tvf backup.*.tar

regards,
Bruce Friedman

Greg O wrote:
>  
> If configured correctly, a flexbackup restore for me would
> simply entail:
> 1. Install SME 5.x (or latest) on a blank machine
> 2. Set up the backup device (eg /mnt/backup in fstab or
> whatever)
> 2. Copy across the backup/restore custom template and expand it
> 3. Run the restore.
>

[Rob Wellesley]

Bruce Friedman wrote:
>
> The process I would use to restore (haven't tried it BTW) is
> to follow your list
> below, including mounting of the backup directory like in the
> script I gave, and then run the following command:
>
> tar xf backup.*.tar
>

So I point the restore at the directory with the backup files and execute the above?  No need to define which segment restores in what order?

Rob

[Bruce Friedman]

I haven't tried a restore yet, but based on the fact that tar will not allow compression when producing a multi-volume set, I believe they each stand on their own.

Keep in mind that the restore paths are relative, so you need to be in the directory you wish to restore to.  For example, if you were at "/", you need that to be your current directory when you enter the "tar xf backup.*.tar" command.

Rob Wellesley wrote:
>
> Bruce Friedman wrote:
> >
> > The process I would use to restore (haven't tried it BTW) is
> > to follow your list
> > below, including mounting of the backup directory like in the
> > script I gave, and then run the following command:
> >
> > tar xf backup.*.tar
> >
>
> So I point the restore at the directory with the backup files
> and execute the above?  No need to define which segment
> restores in what order?
>
> Rob

[Greg O]

I've decided to do some testing by attempting a restore from said backups, and I can't make it work.

I've tried:
1.
tar --directory / --extract --file /mnt/backup/backup.*.tar
(or cd /  ;   tar xf /mnt/backup/backup.*.tar)
Seems to process the first, then returns 3 lines:
/bin/tar: /mnt/backup/backup.2.tar: Not found in archive
/bin/tar: /mnt/backup/backup.3.tar: Not found in archive
/bin/tar: /mnt/backup/backup.4.tar: Not found in archive
It seems to me that tar is looking IN backup.1.tar for the files backup.<2-4>.tar!

2.
tar --directory / --extract --file /mnt/backup/backup.1.tar
tar --directory / --extract --file /mnt/backup/backup.2.tar
tar --directory / --extract --file /mnt/backup/backup.3.tar
tar --directory / --extract --file /mnt/backup/backup.4.tar
Seems to work, then gives errors, including messages about "from another volume" etc. My guess is that because I'm running the command separately 4 times, the files that span archives aren't restoring properly.

Now I'm sure this is a simple problem, but I can't think of how to fix it.

TIA,
Greg.

[Bruce Friedman]

Greg,

> I've tried:
> 1.
> tar --directory / --extract --file /mnt/backup/backup.*.tar
> (or cd /  ;   tar xf /mnt/backup/backup.*.tar)
> Seems to process the first, then returns 3 lines:
> /bin/tar: /mnt/backup/backup.2.tar: Not found in archive
> /bin/tar: /mnt/backup/backup.3.tar: Not found in archive
> /bin/tar: /mnt/backup/backup.4.tar: Not found in archive
> It seems to me that tar is looking IN backup.1.tar for the
> files backup.<2-4>.tar!
>

Try this command on backup with the multivolume option (--multi-volume) that was used to create the backup.

regards,
Bruce

[Greg O]

> Try this command on backup with the multivolume option
> (--multi-volume) that was used to create the backup.

Ok, I've tried the following:
tar --directory / --extract --multi-volume --new-volume-script /home/e-smith/files/ibays/backups/files/new_restore_volume.sh --file /mnt/backup/backup.*.tar

tar --directory / --extract --multi-volume --new-volume-script /home/e-smith/files/ibays/backups/files/new_restore_volume.sh --file /mnt/backup/backup.1.tar

new_restore_volume.sh simply increments a number and outputs to screen: "Processing volume "

Using either method, the procedure keeps going and going and going. I have reached very high 'volume' numbers (eg 77 - remember, the backup files that i'm trying to restore are only 4 in number!) before cancelling (ctrl-c) and trying another way. FYI, I've sometimes checked the contents of the server after I've cancelled a restore. It _seems_ that I've got all (or at least an overwhelming majority) of my files restored and complete.

TIA,

Greg.

PS: Arg, getting so frustrating. It's such a simple thing, there's gotta be SOMETHING dumb that I'm doing to make it not work.

[Greg O]

Fixed it!

Consorted with my local linux users' group, and found out that tar multi-volume always wants to look at the same filename. ie i've now set the restore newvolume script to delete the most recent (ie finished with) tar file, and rename the next one to it.

eg files:
backup.tar, backup.1.tar, backup.2.tar

how the script works:
process backup.tar
delete backup.tar
rename backup.1.tar to backup.tar
process backup.tar
delete backup.tar
rename backup.2.tar to backup.tar
process backup.tar
delete backup.tar

The dude that found my problem actually suggested that I use symbolic links, but I'm using an smbfs share (he said I'd have to work around that), so I decided it was easier to just delete files and rename. I suppose I don't need to delete, but it's easy and smooth.

Works like a charm!

Thanks for all the help, I'm now content that I can restore in the event of a catastrophe!

Cheers,
Greg.

[rob wellesley]

Greg O wrote:
>
> Fixed it!
>
> Consorted with my local linux users' group, and found out
> that tar multi-volume always wants to look at the same
> filename. ie i've now set the restore newvolume script to
> delete the most recent (ie finished with) tar file, and
> rename the next one to it.
>

Hi

Any chance of a copy of your reworked script?

and any helpful hints would be much appreciated


Rob

[Lester Bennett]

I started off using the standard backup to workstation option in SME 5.5 to backup to a Win2K workstation. If a user deleted or over wrote a file I could use Winzip on the workstation to find and extract it. Then I hit the 3.99GB brick wall. I've just made the changes in the flexbackup-howto but it's gone from bad to worse, I now only get a 2GB file. If I implement the fragmented file option, how do I extrat a single file from the backup at the workstation?

Lester Bennett

[Greg O]

*sigh* Is it really 8 months since I last posted on this? I suppose the computer never lies ):

Anyway, I never posted that complete script, because I was waiting until I had the time to get a backup restored properly, as a test. As you can see, I never got that test done - in fact, I tried a few times, and it failed for different reasons (mainly to do with tar...)

Basically we've given up on tar backups. They're backed up ok (except maybe for any file that's stored partially over two volumes), but the voluming doesn't ever seem to work properly when restoring. We actually had a critical outage of some data, and had to use these bodgy backups, which was quite a problem, because as I told the new guy - they don't restore! Anyway, he knows more than I, and whipped out a desktop distro with a graphical backup utility - ark, I think it was. Ark saw the contents of the individual tar files ok, and restored them... all except for those files that span across to tar files.

Long story short, we're now using rsync to backup, and are considering looking at Mike Rubel's snapshot method:
http://www.mikerubel.org/computers/rsync_snapshots/
In fact, Rob had a suggestion along with that - although I can't remember what it was, since the job of our backups is no longer mine, and our current setup actually works - praise the Lord!


So Lester, grab ark if you want an individual file. I'd suggest copying the whole archive (pick the specific volume if you know which one it is) to the local machine that's got ark or whatever on it. btw WinZip plain refused to see a 2GB file (:

Yep, I ticked the "commercial tape backup" option on the survey at http://www.e-smith.org (:

Bruce & Rob and others - thank you for all of your help over the last 12 months with this problem. I've really appreciated having people willing to help in a land where I am rather a stranger. I only hope you haven't had such issues (it sounds like you haven't).

Good luck!
Greg.

[Rob Wellesley]

go to contribs.org and search for backup2ws

[Lester Bennett]

Bruce,

I've installed your scripts, had to change #!/bin/sh to #!/bin/bash before it would run, not sure why. No it runs but I get the following error when giving the domain admins name and password.

mount error: Device or resource busy
Please refer to the smbmnt( manual page.
smbmnt failed: 255

When I give a workstation users name and password I get

session setup failed: ERRDOS - ERRnoaccess (Access denied).
SMB connection failed.

Can you shed any light on this. I bet it's basic Linux stuff but forgive me I'm only a newbie.

Lester Bennett

[Robert Poirier]

II would like to suggest you using RARLinux since it support all those options needed.  RARLinux support spanning and it compress well by nature.  So wouldn't  that be a good solution to backup to an SMB share?  Would it be possible to include it to FlexBackup to do the job?  

 I actually tried it once and it did the job very well.  (did'nt restore but I dought there would be any trouble)

I would also like to point out that I'm not a guru so please dont be too hard on me.

I just wanted to submit the Idea ....