2015-12-25 4 views
2

I есть postgresql DB на Azure VM с установленной Linux. Мне нужно восстановить некоторую резервную копию из файла с именем latest.dump. Я скопировал этот файл в /home/myuser, а затем побежал psql mydb < latest.dump.Восстановление резервной копии postgres завершается с ошибкой, и появляется файл восстановления с причудливым именем (??? 2 @ ؾ>? Yqus ????> I? [ޏ I ?? i? Ď) появляется в/home/myuser

Много тарабарщины получено на экране, например.

ERROR: invalid byte sequence for encoding "UTF8": 0xb3 
invalid command \Jg�~J&�:�Qr�Ɩ����q���^�[1�����q)���G���҆C�|� 
ERROR: invalid byte sequence for encoding "UTF8": 0xb5 
invalid command \mJ�q����>�^�R���� 
invalid command \R 
        ܡI$�)�a�;���wg7Ei�}R%�Q����h&ஓ�L��܆��(
invalid command \I����3M��e�2Q�?/X������`+=|Y[``+��:��r 
invalid command \�^c�v��rR 

И как только она закончилась, он оставил эту строку предварительно введенные в командной строке:

62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c62;9;c 

Если я нажимаю войти в это, я просто получаю много command not found ошибок.

С большим недоумением, новый файл появился на /home/myuser (то есть на том же уровне, где latest.dump сохранен). У этого причудливого имени [email protected]ؾ>?yqus????>I?[ޏI??i?Ď.

Если я стараюсь sudo rm [email protected]ؾ>?yqus????>I?[ޏI??i?Ď, я получаю rm: cannot remove ‘[email protected]ؾ’: No such file or directory. И затем, если я снова сделаю ls, я вижу два файлов в/home/myuser кроме latest.dump и [email protected]ؾ>?yqus????>I?[ޏI??i?Ď. Эти новые файлы: ?yqus???? и I?[ޏI??i?Ď. Я могу удалить эти два, но никогда не [email protected]ؾ>?yqus????>I?[ޏI??i?Ď. Я замечаю, что имена двух вновь созданных файлов являются частью имени файла исходного файла (где они выглядят отделенными >, если вы внимательно смотрите).

Кстати, я вошел в свою базу данных postgres, чтобы узнать, сработало ли восстановление. Это не было, данные не были заполнены, а psql mydb < latest.dump по существу не удалось.

Может ли кто-нибудь указать, что, черт возьми, происходит здесь, и как я могу удалить эти вновь созданные ошибочные файлы?


Внутри latest.dump я вижу, SQL, как:

^@^@^@^@^@^A^A^@^@^@^@^F^@^@^@public^A^A^@^@^@^@^N^@^@^@uauvuro0s8b9v4^@^E^@^@^@false^@^C^@^@^@246^A^A^@^@^@^C^@^@^@^@^@^@^@^@^@ñ^@^@^@^@^@^@^@^@^@^D^@^@^@1259^@^E^@^@^@44416^@^R^@^@^@links_grouptraffic^@^E^@^@^@TABLE^@^B^@^@^@^@±^@^@^@CREATE TABLE links_grouptraffic (
    id integer NOT NULL, 
    visitor_id integer NOT NULL, 
    which_group_id integer NOT NULL, 
    "time" timestamp with time zone NOT NULL 
); 

И много данных 'бредом', как:

¿f ^?zQUò}ÛMpá#"  ^]äR¡g¤^E ¼å<9a>ÓÍ@î<98>,£+DØñW[^Mw<8f>Ív<9d>ñItâduM§[/úµ<8c>ÏVgý[D^W3^N^Z0<91>Õ]'/ݸ1<8c>Ã^T°<8b>ªÈw42Á<87>Ç@o#Ñ<99>á<9c>¹=^@/áÙ¢<8c>´M Sç<90>|<æÇ<9d><93>¥<9a>NÜ©^CáxuXÜî¬<89>Ü^NÙo<8c>ð³°^O§ p¸ñÌÔ3}+^Oâr<3M¾<9b>t<80>^D<84>A^CÈ<89>kå^^H±yò ­T^Bíâ"º d<85><85><88>o<89><80>±³^C¥Ä9½^V^W4<81>æ¨ïo^YO[(æÃù^M^RÁ<9e>Ò<8e>Ô§k=ý<87>vGõº><83>^Q^DÅ>Û<~¡Ô+í 

Примечание: пожалуйста, обратитесь за дополнительной информацией в случае необходимой

+0

Ваш дамп не кодируется UTF-8 или, возможно, не содержит операторов sql. – pvg

+1

Это приложение, которое в настоящее время работает и работает правильно. Я использовал 'heroku pg: backups capture' и' curl -o latest.dump heroku pg: backups public-url', чтобы взять дамп. Мое приложение - приложение для чата, и некоторые пользователи могут вводить символы не UTF8. Есть ли что-то, что мне нужно делать по-другому, когда вы принимаете pg_dump? –

+0

вы посмотрели на свалку? это звучит как возможные проблемы с кодировкой, но вы проходите через многие уровни косвенности. что герпику сваливают? какова стандартная кодировка вашего db? «кто-то набрал глупый персонаж», вероятно, не является основной причиной здесь. – pvg

ответ

1

Во-первых, чтобы удалить файл. Попробуйте использовать rm "filename" (т. Е. Поместите цитаты вокруг имени файла). Если это не сработает, то ? в имени файла, вероятно, является некоторым другим символом. Вы все равно можете удалить его, используя свой inode. Сделайте ls -li и обратите внимание на номер inode (слева). Затем просто запустите команду find . -inum <inode-number> -exec rm -i {} \;. Это должно избавиться от проблемы номер 1.

Во-вторых, я предлагаю не использовать psql mydb < latest.dump. Вместо этого используйте pg_restore так: pg_restore latest.dump -d mydb -U myuser. Технически, это правильный путь для вас. Вы можете получить дальнейшие ошибки, но они не будут связаны с тем, что вы видите в данный момент (и может даже быть невежественным). latest.dump, вероятно, является двоичным файлом вместо текстового файла. Удачи!

 Смежные вопросы

  • Нет связанных вопросов^_^