--On Mittwoch, 6. Dezember 2006 09:42 +0100 User100 <[EMAIL PROTECTED]> wrote:
>> -----Ursprüngliche Nachricht----- >> Von: Alan Brown [mailto:[EMAIL PROTECTED] >> Gesendet: Dienstag, 05. Dezember 2006 13:42 >> An: User100 >> Cc: bacula-users@lists.sourceforge.net >> Betreff: Re: [Bacula-users] Restorejob bigger than space on >> originalserver (no delete record) - possible workaround but... >> >> >> >> > So in theory when creating a filelist we have just to restore the >> > filelist.txt from the last incremental set and make the >> full restore based >> > on this filelist with option "7: Enter a list of files to >> restore" and >> > enter "<filelist.txt". However it seems this function tooks >> "long" with >> > entries >10000 and "useless long" with many entries >100000 >> here. Does >> > anybody have an idea how to workaround another way or to >> speed this up >> > great? >> >> This is exactly what's been discussed here over the last >> couple of weeks >> in terms of point-in-time restores of large backups (which is >> functionally >> similar to a migration job and almost identical to a verify job) >> >> AB >> > > Thanks for your information. I made a look into: > http://www.bacula.org/dev-manual/Migration.html but I´m not sure how it > could help to move data from one volume to another and it seems to me a > little bit like another "workaround"? I´m afraid this took more > additional backupspace than a simple filelist which was included on the > incremental backups and isn´t there the same problem that no > delete-record is done? If I made on fulljob in the past and have some > incremental sets from one client how should the migration job know that > he should just include files that current exist on the client so I don´t > risk to fill up my server on a disaster? I think if I need to restore > just one folder which was deleted by a busy user than double-names should > not be so critical but if I need to restore a crashed server than normaly > I don´t care about "lost files" but need to restore the last known > working state (and no duplicates which could avoid this step by filling > up my harddrives). > Um, I think Alan meant the thread "Incremental backup, not accurate?" You can find it here: http://gmane.org/ also currently project no. 3: <http://www.bacula.org/?page=projects> regards, Georg ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
