Hi, Sorin Srbu wrote on 2011-04-14 08:33:10 +0200 [Re: [BackupPC-users] How to restore an 8GB archive file?]: > >-----Original Message----- > >From: Jeffrey J. Kosowsky [mailto:********@********.org]
please don't do that. At least now I know why I'm getting spam to my backuppc-list-only email address. > >To: General list for user discussion, questions and support Much better, though this address is probably less sensitive ... > >Cc: [email protected] Your problem :-). > [...] > Moving the 8GB archive to a machine with ext4, solved the problem. I agree with the other opinions. Amongst other things, you changed the file system. I doubt this was the relevant change. > OTOH, ext3 is said to have a max file size limit from about 16GB up to > some 2TB, depending on block size. Several years ago, I worried about file sizes, too. It turned out to "just work" even back then. I haven't encountered such limits in years. Then again, on relevant file systems I don't tend to use ext3, because it *still* seems to have occasional problems with online resizing (admittedly on a Debian etch installation; might have gone away since). Huge files seem to go hand in hand with online resizing requirements. Sorin Srbu wrote on 2011-04-14 08:37:54 +0200 [Re: [BackupPC-users] How to restore an 8GB archive file?]: > [...] > >From: Les Mikesell > >Sent: Wednesday, April 13, 2011 5:10 PM > >>> Why don't you just restore it back to his machine, using the typical > >>> option 1? If BackupPC archived it in the first place, it can restore it > >>> the same way. > >> > >> I've never had that option to work. This time I got a weird "unable to > >read 4 bytes"-error when trying a direct restore. > > > >Usually that means the restore is configured to use ssh in some way, and > >the ssh keys aren't set up correctly. Is there something different > >about the way your restore command works? > > I do use passwordless login for the backups to work. The backup works fine > using ssh this way; I don't get prompted for a password. > > Not sure though, how you mean different for restoring. Could you elaborate a > bit? You've got it the wrong way around. *You* need to elaborate. What are your RsyncClientCmd and RsyncClientRestoreCmd (it was rsync, wasn't it?)? If we knew those, we could see what might be misconfigured or causing problems (or what is even *involved* in backing up/restoring in your setup). > I haven't really looked into the first restore option, ie tweaked in any > way, as #2 and #3 have worked fine so far, until now. Well, then it may be set incorrectly. Or not. Depending on what you did to the backup command. Sorin Srbu wrote on 2011-04-14 08:47:12 +0200 [Re: [BackupPC-users] How to restore an 8GB archive file?]: > >From: Holger Parplies > >Sent: Thursday, April 14, 2011 12:38 AM > > > >- Which user on the target host do you need to connect as? Perhaps root? > > When the "backuppc" user connects to a host to do a backup, it uses a > passwordless login with ssh keys. The password entered the very first time I > transferred the key, was root's. So does this mean it's user "backuppc" that > does the actual restore or user "root"? Well, you took away the context, so it's not obvious you misunderstood the question (which wasn't one, actually). If you use computers to do things, you need to think. There is no way around that. Even a nice shiny GUI does not have a "do the right thing, now" button. Downloading a tar file over the GUI requires you to think about where to do that and how to get the tar file to the destination computer, as the right user, and where to put it. There might be a simple solution (go to the destination computer and download the tar file from a browser belonging to the user, and he'll tell you where to put it), but there might as well be many obstacles (not enough tmp space, broken browser version, no network access to the BackupPC server, slow network link, transparent proxy, user out for lunch, user needs to leave before the download is complete ...). Some of these might even impose *arbitrary* file size limits when downloading (browsers seem to have *strange* solutions for starting downloads before they know where to put the file). You might "automatically" select the right option, or you might not think about it at all and just get away with it. Or hit something that looks like a file system problem, but can't really be explained. Concerning the selection of an ssh target user, if you want a generic answer, use root, that will always work (but has the potential to do more harm if you get something wrong). For your case, if you *can* log in as the file owner (all files in the restore belong to him, right?), then do that. Maybe I should have written "select the target user that makes most sense in each respective case". All of this has *nothing* to do with BackupPC doing backups. It's only about *you* getting the user's files back on his computer. And it's coincidentally similar to how automatic restores would work, except that they need a generic (and non-interactive) solution, whereas you can use anything that works for you. Setting up automatic restores is an independent matter. I make a habit of expressly disallowing automatic restores, because it's too easy to overwrite valid, new data (that has not been backed up yet) with old versions by clicking on the wrong buttons in the GUI. Restores are a potentially destructive operation and require thought and concentration. But that's just my opinion. If you like the GUI, feel free to set up automatic restores. > If the first, then I can understand that the user backuppc can't write to > anywhere, right? For backups, BackupPC also needs to *read* files that any random user may not have access to, so there is generally a method of getting root permission involved ('ssh -l root' or 'sudo'), unless your backups are supposed to contain only files readable by a certain user. > >Personally, I wouldn't use the web interface for downloading large amounts of > >data anyway. On the command line, your imagination is the limit to what you > >can do. [...] > > Dunno', I only ever use the web gui, as it's so easy, practical and > straight-forward to use. Actually it's the main reason why I stick with BPC; > IMHO a backup-system is as good as the gui is and how admin-friendly it is. Yes, the interface needs to be admin-friendly. I define that as 'flexible'. GUIs can't be as flexible as a command line. So, for me, a backup-system is as good as the command line interface is. Well, no. The primary job of a backup system is to do backups and allow restores. If it's not reliable, then I don't really care about GUI or CLI. Luckily, most of BackupPC's actions just happen automatically without admin action. The GUI is great for checking the status. The rare event of a restore is painless enough, and I don't have to 'jump through hoops' to prevent them from being in-place. > Personally I don't want to jump through hoops when I need to restore stuff > quickly My point exactly. I don't want to google what might be causing problems with my 8 GB file (which is purely temporary), then run around and try all computers until I find one where I can temporarily store the file, install a new OS version somewhere if I don't find one, copy the file over the network and from one disk to another several times ... why should I, when I can avoid the large file (and the need to store it somewhere) altogether and be done with the one single network transfer I can't get around anyway? > - a few clicks in the gui and I'm done. That does not seem to be what happened in this case ;-). > As I said, it's my personal opinions and maybe not really on-topic. 8-) That's fine, and that's what the GUI is there for in the first place. I had, perhaps mistakenly, assumed that the command line version is quite straightforward - it is, really, if you have set up and understood automatic restores. So let's get back to that topic, if you're still interested. Regards, Holger ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
